Lazy evaluation is perhaps the most powerful tool for modularization in the functional programmer’s repertoire. Consider …

Most functional programming languages have a function called “repeat” which generates an infinite list; its argument is used as the value of the list. For example, this generates an infinite list of 3:

        repeat 3        returns [3, 3, 3, …]

Also provided by most functional programming languages is a function called “take” which has two arguments, an integer N and a list. The function “take” returns the first N values of the list.

“take” can be composed with “repeat” to obtain a pruned list of values. The following returns the first 5 values of an infinite list:

        take 5 . repeat

Function composition is denoted by the dot ( . )

Applying that composed function to 3 results in a list of five 3′s:

        (take 5 . repeat) 3        returns [3, 3, 3, 3, 3]

It is lazy evaluation that allows us to modularize the pruning problem in this way. The “repeat” function is evaluated lazily – only as many values as requested are generated. So lazy evaluation is very efficient. Without lazy evaluation we would have to fold these two functions together into one function which only constructs the first five values.

Here’s another example. We can define the set of even numbers by enumerating all positive numbers [1..] and multiplying each by 2:

        evens = [x * 2 | x <- [1..]]

That is, of course, an infinite list. However, lazy evaluation will compute only as many as needed. Let’s take the first 5 evens:

        take 5 evens        returns [2, 4, 6, 8, 10]

One more example. The example comes from the field of Artificial Intelligence. A decision tree is generated. It could be a decision tree for medical diagnosis or a decision tree for chess moves or a decision tree for something else. The decision tree is potentially infinite. Without lazy evaluation, processing may never terminate. Rather than exploring a potentially infinite space we prune the tree to a depth of, say, 5 levels:

        prune 5 . decisiontree

decisiontree is a function that generates the tree. prune 5 chops off any levels of the tree beyond 5 levels deep. We can make improvements by tinkering with each part. Without lazy evaluation we would have to fold these two functions into one function which only constructed the first five levels of the tree. That is a significant reduction in modularity.

Lesson Learned: Want to have successful software? Then you need to learn how to take advantage of the enhanced modularity that lazy evaluation provides. And, of course, you need to use a programming language that supports lazy evaluation.

public IEnumerable<int> MakeGenerator(int num0)
{
    yield return num0;    

    int i = 0;
    Console.WriteLine("yield 0");
    yield return 0;
    try
    {
        i += 1;
        Console.WriteLine("yield 1");
        yield return i;
    }
    catch {}
    Console.WriteLine("end");
}

The code above will return a IEnumerable, and will not do anything else, until the IEnumerable is used. In other words, if I invoke MakeGenerator, none of the code I wrote will actually be run. Now, this might sound completely ridiculous, but I assure you, there is a good reason for this. To explain it as simple as possible, consider the following code, what would you guess the output to be like?

foreach(int num in MakeGenerator(5))
{
    Console.WriteLine("Got " + num);
}

The answer might surprise you. If you run the code above, you will get 6 lines of output, in the following order:

Got 5
yield 0
Got 0
yield 1
Got 1
end

The reason for this is that first when GetNext on the enumerator which the foreach-loop get’s from the IEnumerable is called, the code in the MakeGenerator-method is actually run. However, as you can see, not all of it is run. When we hit any of the yield-statements, the method is returned from. Now, this is a construct that’s actually quite useful in a lot of cases, cause for once, it enables lazy evaluation of your code over enumerables. LINQ for once, relies heavily on this (note; I do not know if LINQ uses yields or customarily created enumerators, but they both facilitate lazy evaluation over enumerables). For instance, if you have a list of a million elements (called myList), and you do myList.Select(CpuHeavyMethod), this will not fry your CPU into oblivion, rather, it will not run the CpuHeavyMethod at all! First when you actually have need for an element passed through the CpuHeavyMethod it will be called.

For those of you who still do not know what a generator is, you can learn more here: http://en.wikipedia.org/wiki/Generator_(computer_programming)

Creating generators

Now that (hopefully) all of you have a basic understanding of what generators are, and how they work, let’s look at how to make them. In other words, let’s look at what the compiler does with the yield keyword. Now, before I start, I’d just like to say that this is most likely different from language to language, and this may or may not be the way C# handles compiling generators (I’ve not looked at how the C#/mono compiler solves the problem, what I’ve read is how the IronPython compiler/interpreter does it. However, I’ve also changed that a bit to simplify).

As it turns out, generating generators is actually rather simple, there are just a few things you have to look out for:

• Try statements (with or without finally) must be handled separately (and with a little bit of caution).
• There cannot be yield-statements in catch or finally-blocks.

Note: these are rules I’ve set for the generator I create. It may be possible to have yields in both catch and finally in C#, though it would require further rewriting of the method, and will not be discussed in this article.

The first thing we need to do (in C# anyways) is to create 2 classes. One for the IEnumerable, and one for the IEnumerator. Also, these two classes will be nested, to enable the inner one to access the outer one’s private variables.

Let’s start with these two completely empty classes (save for the interface-implementations, and _state and _current values which I’ll get back to later).

class MakeGenerator_Generator : IEnumerable<int>
{
	IEnumerator<int> IEnumerable<int>.GetEnumerator()
	{
		return new MakeGenerator_Enumerator(this);
	}

	IEnumerator IEnumerable.GetEnumerator()
	{
		return new MakeGenerator_Enumerator(this);
	}

	class MakeGenerator_Enumerator : IEnumerator<int>
	{
		private readonly MakeGenerator_Generator _gen;
		private int _state = -1;
		private int _current;

		public MakeGenerator_Enumerator(MakeGenerator_Generator gen)
		{
			_gen = gen;
		}

		int IEnumerator<int>.Current
		{
			get { return _current; }
		}

		object IEnumerator.Current
		{
			get { return _current; }
		}

		bool IEnumerator.MoveNext()
		{
			throw new NotImplementedException();
		}

		void IEnumerator.Reset()
		{
			throw new NotImplementedException();
		}

		void IDisposable.Dispose()
		{
			throw new NotImplementedException();
		}
	}
}

The first thing we need to do is to take all the method-parameters given to the MakeGenerator method and make them class-level readonly members of the Generator-class. Then we need to add a constructor that takes the same number of arguments, and saves them to the class members.

class MakeGenerator_Generator : IEnumerable<int>
{
	readonly int param_num0;

	public MakeGenerator_Generator(int num0)
	{
		param_num0 = num0;
	}

Then we need to copy those to private members of the Enumerator-class during it’s Reset() call, and lastly we need to call Reset() from the constructor like this:

	class MakeGenerator_Enumerator : IEnumerator<int>
	{
		private readonly MakeGenerator_Generator _gen;
		private int _state;
		private int _current;
		private int val_num0;

		public MakeGenerator_Enumerator(MakeGenerator_Generator gen)
		{
			_gen = gen;
			((IEnumerator)this).Reset();
		}

		void IEnumerator.Reset()
		{
			val_num0 = _gen.param_num0;
		}

The next thing we need to do is to copy the entire content of the original method into the MoveNext method of the Enumerator (note, this will make for invalid code, but we’ll fix that in a bit). The result should look like this:

		bool IEnumerator.MoveNext()
		{
			yield return num0;

			int i = 0;
			Console.WriteLine("yield 0");
			yield return 0;
			try
			{
				i += 1;
				Console.WriteLine("yield 1");
				yield return i;
			}
			catch {}
			Console.WriteLine("end");
		}

Now that we have the base-foundation of the generator, we can start editing the original code to make it work as a generator (in other words, rewrite it to a proper MoveNext method).
What needs to be done in the MoveNext methods is two things for startes. First; all variables needs to be hoisted out to class-level variables, and second, we need to enumerate the yield-statements (starting from 1). Than you change the nth yield-statement into this:

_state = <n>;
_current = <yield_value>;
return;
yield_label_<n>:

The result of doing those two actions looks like this:

		bool IEnumerator.MoveNext()
		{
			_state = 1;
			_current = val_num0;
			return;
			yield_label_1:;

			val_i = 0;
			Console.WriteLine("yield 0");

			_state = 2;
			_current = 0;
			return;
			yield_label_2:;

			try
			{
				val_i += 1;
				Console.WriteLine("yield 1");

				_state = 3;
				_current = i;
				return;
				yield_label_3:;
			}
			catch {}
			Console.WriteLine("end");
		}

For those of you who have never seen a label in C# before, this code might look a bit confusing. A label in C# is created by typing a name followed by a colon, like “yield_label_0:” The use of a label is with goto, where you jump to a label. The reason I’ve added a semicolon after the label, is simply to add an empty statement you jump to. This would not strictly be necessary, however, if I do not the yield_label_3 would be invalid (as you cannot have a label that goes “off a cliff”, ie. out of a method, if, while, block, etc.). The next part is simply to add a switch over the state in the beginning of the MoveNext method, that jumps to the right continuation. Also, we need to add the final state (_state == 0, finnished). The result looks like this:

		bool IEnumerator.MoveNext()
		{
			switch(_state)
			{
				case 1: goto yield_label_1;
				case 2: goto yield_label_2;
				case 3: goto yield_label_3;
				case 0: goto yield_label_0;
			}

			_state = 1;
			_current = val_num0;
			return;
			yield_label_1:;

			val_i = 0;
			Console.WriteLine("yield 0");

			_state = 2;
			_current = 0;
			return;
			yield_label_2:;

			try
			{
				val_i += 1;
				Console.WriteLine("yield 1");

				_state = 3;
				_current = i;
				return;
				yield_label_3:;
			}
			catch {}
			Console.WriteLine("end");

			_state = 0;
			yield_label_0:;
			return _state != 0;
		}

This is basically a working generator. The two first values would work just fine if we simply left it like this (and removed the try), however, since we do have a try (cause I wanted to show how to solve this), this is what we do.

1. Start with the outermost try (only do this if the try contain yield-statements).
2. Create a new label in front of the try.
3. Rewrite all goto-statements that point to a yield inside the try so they point to the new label instead.
4. Rewrite the try so it jumps based on state.

In other words, it goes like this:

switch(_state)
{
	case 1: goto yield_label_1;
	case 2: goto yield_label_2;
	case 3: goto try_label_1; // 3. Rewrite goto-statement to point to start of try
	case 0: goto yield_label_0;
}

_state = 1;
_current = val_num0;
return;
yield_label_1:;

val_i = 0;
Console.WriteLine("yield 0");

_state = 2;
_current = 0;
return;
yield_label_2:;

try_label_1:; // 2. create label in front of the try
try
{
	switch(_state) // 4. Rewrite the try so it jumps based on state
	{
		case 3: goto yield_label_3;
	}

	val_i += 1;
	Console.WriteLine("yield 1");

	_state = 3;
	_current = i;
	return;
	yield_label_3:;
}
catch {}
Console.WriteLine("end");

_state = 0;
yield_label_0:;
return _state != 0;

And there you have it. We’ve made ourselves a generator. The only thing that needs to be fixed now is to remove the NotImplementedException inside the Dispose-method. What you should probably do inside the Dispose-method is set the _gen-variable to null, and check for it being null in both MoveNext and Current (and if it is, throw a InvalidOperationException because it’s already disposed), however, I’ll leave that up to you guys. Also, I was planing on showing how to create Generators with the DLR, though it seems this post became longer than I planned it, and if I were to start explaining the DLR stuff now, I’d probably more than double the length, so that will come later. I hope this made it easier to understand how generators work, and what the compiler does with them.

Until next time.
- Alxandr

• myCollection.Count() > 0
• myCollection.Any()

Both operations seem to be correct. When an item exist in a list both operations returns true and a Unit test to test whenever it returns true will pass. However it is better not to use the Count method. Especially when using large data sets.

myCollection.Count() > 0
Intellisense about Count: Returns the number of elements in a sequence.  This means when you use Count() > 0 to check whenever the list contains an item, the list must be filled with items. When using large data sets it first retrieves all the data and then calculates the number of elements.

myCollection.Any()
Intellisense about Any(): Determines whether any element of a sequence satisfies a condition. When using the method Any(), it only needs to know whenever 1 items exists in the list. This is way faster than first counting the numbers of items.

To demonstrate the difference in speed use the following scenario. Create a console application, .net framework 3.5 or higher, and replace the Program.cs code with this code:

using System;
using System.Linq;
using System.Collections.Generic;

namespace ALotToLearn.CountAny
{
    class Program
    {
        static void Main(string[] args)
        {
            var numbersCount = Numbers();
            var numbersAny = Numbers();

            if (numbersCount.Count() > 0)
                Console.WriteLine("A number exists in the collection ");

            if (numbersAny.Any())
                Console.WriteLine("A number exists in the collection ");
        }

        static IEnumerable<int> Numbers()
        {
            yield return 1;
            yield return 2;
            yield return 3;
            yield return 4;
            yield return 5;
            yield return 6;
            yield return 7;
            yield return 8;
        }
    }
}

When you run the program it will display “A number exists in the collection” twice. Now run the program with a breakpoint at line 11 and step through the code.

The first thing that you will notice is that the Visual Studio doesn’t step into the Numbers() method, when you assign the collection to the variables. This is because the compiler is using lazy evaluation for that method. The method, and the results, is only called when we actually need the data. This will decrease the number of calculation while running the application. Please read the Wikipedia page for more information about lazy evaluation.

When you step into line 14 you will notice that the Visual Studio is stepping into the Numbers() method. We now need that data to calculate the numbers. You will see that it stepped over every yield return. This is because every number is needed to return the number of elements in a sequence. Of course the Count is higher than 0, it returns true and a Unit test, when we had created one will pass.

Now step into line 17. You will now notice that Visual Studio is stepping into the Numbers() method but at the first yield return it will stop calling the method. This is because the Any() method has found an item that satisfied a condition, returns true and… you know the rest.

This example did not show the big impact it can have, but imagine you connecting to a potentially large database and need to know a particular table has an item.

Happy coding!

惰性求值是函数式编程里面非常常见并且非常有用的一种求值策略。正如名字所暗示的：尽可能将求值计算拖到最后不得不算的时候。高阶函数和惰性求值可以视为函数式编程的左右使，为程序的模块提供了非常强大的方法。

这篇博客使用惰性求值来 表达 牛顿平方根算法。数值算法的思路一般就是采用无穷逼近的方法得到任意精确的结果（但不是准确的结果），基本思路如下：

如果 a 是 n 的平方根，那么 a^2 = n
如果 a0 近似 n 的平方根，由这个近似值可以推测更近似的下一个值： a1 = (a0 + n/a0) / 2
类似的： a2 = (a1 + n/a1) / 2
…
an+1 = (an + n/an) / 2

这样我们能得到一个无穷序列： [a0 a1 a2 … an … ]，越是后面的项，（可以证明当a0取值合理的时候）越接近 n 的平方根。由于计算机不能表示无穷精确的数据，在实际运用中会有一个精读取舍，比如求值到 an^2 与 n 的差值小于 0.0000001，或者 an 与 an-1 的差值小于 0.0000001 等等，作为算法（计算）结束的条件。

迭代求值的版本

(declare good-enough? improve)
(def err 0.00000001)

(defn iter-sqrt [n guess]
  (if (good-enough? guess n)
    guess
    (iter-sqrt n (improve guess n))))

;上述是递归函数（实际上迭代，因为是尾递归）是求值的过程。

(defn improve [guess n]
  (/ (+ guess (/ n guess)) 2))

;improve 就是计算序列中的下一项。

(defn good-enough? [guess n]
  (letfn [(abs [x] (if (< x 0) (- 0 x) x))]
    (< (abs (- (* guess guess) n)) err)))

;good-enough? 使用近似值的平方与被开方数的差值作为衡量标准。

(println (iter-sqrt 2 1.0))
;= 1.4142135623746899

事实上，上述代码在 Clojure-JVM 中实际执行的时候，并不会针对尾递归左右，因为JVM识别不了，如果需要优化，则需要在 Clojure 代码中存在尾递归的地方使用 recur 代替递归函数， Line7 修改为：

(recur n (improve guess n))

上面迭代求值是很自然的，但存在潜在的问题：终止条件 good-enough? 在 iter-sqrt 内部，如果用户想修改精度，或者修改精度测试方法怎么办？当然可以使用“回调函数”的方法，将 good-enough? 作为 iter-sqrt 的参数传递下来：

(defn iter-sqrt [n guess good-enough?] ...)

看起来不错，但是 good-enough? 的参数怎么定？新的测试方法如果依赖不同的数据怎么办？（比如需要序列中的相邻两项）。这便是回调函数的问题，看似很灵活，但实际上没有 根本地 解耦。如果我们将 good-enough? 完全给用户去做，iter-sqrt 完全不理会 good-enough? 会怎样？这个方案是不是很理想，将问题彻底地分解了 —— 生成（序列）和判断（终止条件）的分离。Clojure 或者函数式编程能提供这样一种模块化能力，这个能力有赖与惰性求值。让我们用 lazy 的思维重新分析上述问题。

惰性求值的版本

函数式编程的一个重要思维是：置底向上（Bottom-Up，参见 Paul Gramhan 的 On Lisp)，就像复合函数是有简单函数一步一步组合起来的，最终构了完整的解答，你不可能一开始就拿出那个最大的函数 —— 这是不可能的。首先我们考虑序列。

序列可以分为两个函数，一个用来计算下一项，另一个用来构建这个序列：

(defn next-item [n]
  (fn [a]
    (/ (+ a (/ n a)) 2)))

这是一个高阶函数，(next-item n) 返回计算 n 的平方根序列中下一项的函数，所以2的平方根序列可以表示为：
[ 1.0
((next-item 2) 1.0)
next-item 2) ((next-item 2) 1.0
next-item 2) ((next-item 2) ((next-item 2) 1.0)
…]

(defn lazy-sqrt [calc-next start]
  (lazy-seq
    (cons start
      (lazy-sqrt calc-next (calc-next start)))))

(defn good-enough? [seq-sqrt err]
  (let [f (first seq-sqrt) n (fnext seq-sqrt)]
    (letfn [(abs [x] (if (< x 0) (- 0 x) x))]
      (if (< (abs (- f n)) err)
        n
        (good-enough? (rest seq-sqrt) err)))))

(println (good-enough? (lazy-sqrt (next-item 2) 1.0) 0.00001))
;= 1.4142135623746899

上面的计算可以翻译成：比较之前的迭代版本是不是“说得”更好？

参考

1. Abelson, H. and Sussman, G. J. – 计算机程序的结构和解释（SICP）
2. John Hughes – Why Funtional Programming Matters

Via FINCAD on Pinterest http://pinterest.com/pin/11470174021588278/. Information based on report with the same name http://www.fincad.com/derivatives-resources/white-papers/risk-measurement-on-demand.aspx

In the code below, we define a FullDogDescription property that is read-only.  The private backing variable is initialized to an empty string and we only calculate its value in the get accessor when someone tries to read the property’s value.

<pre>        private string fullDogDescription = "";
        public string FullDogDescription
        {
            get
            {
                // Generate full description the first time that
                // someone reads this property.
                if (fullDogDescription == "")
                    fullDogDescription = GenerateDogDescription();

                return fullDogDescription;
            }
        }

The benefit of doing this is that if the call to GenerateDogDescription takes some time, we don’t spend the time calculating a value until some piece of code actually needs a value.

This post in particular is dedicated to a hidden gem that I found, and one that has given me a new way to look at programming and problem solving:

In addition to taking my two core CS courses, Data Structures and Algorithms, I enrolled in a a linguistics course that explores how we can represent and manipulate meaning in a computer.  In order to do that, we are learning Haskell. It is an incredible language. Here’s where I’ve been learning, and here’s the scoop:

It’s functional. What does that mean? I had learned Scheme for my introduction to CS course, but I did not understand the essence of functional programing. It’s based on lambda calculus, which is a system for manipulating functions.  Essentially, the lambda “term” are defined as follows (you can read more here if you’re interested):

1. Any variable or atomic statement, x
2. Abstraction, λx . M – i.e. turn M into a function, with x as the variable
3. Application, (M N) – i.e. replace every appearance of x in M (see 2) with N

It may seem a bit confusing, but it is quite similar to how we think about math.  You have functions, denoted f(x) or the like, and you can apply that function to x.  Alternatively, given some expression (without an equal sign), you can turn it into a function by setting it equal to g(x) or the like.  The single most powerful feature of lambda calculus is the ability to pass a function as an argument to another function.  Just like we can apply a function to a variable or a constant (1), we can also do something like f(g(x)) and get a totally new function which we can then apply to some other expression.  What’s more, and here is a place lambda calculus gets cool, is that if a function takes multiple variables, if we give it a value for one of the variables, it becomes a totally new, and perfectly legal function.  This has tremendous implications for how we can manipulate data, and gives you the opportunity to write highly flexible code.

But enough of my raving.  If you don’t believe me, read this, this, or this.  And get started learning Haskell!  Here are my favorite things about the language:

• Strong typing – the compiler will yell at you if your types don’t match exactly.  Seriously.  And ghc (glasgow haskell compiler) will give you very precise, useful error messages.  This prevents a lot of runtime errors, and usually means that you will have a working program once it has successfully compiled.
• First class functions – since Haskell is functional, there is no concept of “parameters” per se, only terms to which you are applying a function.  Because of this, functions are applied to terms immediately following them, and function application takes the highest precedence.  Say goodbye to parentheses!
• First class math – so many built in functions for math.  One line fibonacci sequence. ‘Nuff said.  Maybe not – the use of guards instead of if-else statements makes code look like real, pencil-and-paper math
• Infinite lists – didn’t think that was possible?  Thank laziness.

Sold?  If you’re interested in learning the language, I would start with Learn You a Haskell, which gives a great rundown of all the important library functions, as well as gives you a good sense of how to use the functional constructs of Haskell.  More advanced programmers may want to look here.

Related articles

• Haskell Lazyness (stackoverflow.com)

This example is a password generator program based on a RandomCharSequence type which implements IEnumerable<char>. RandomCharSequence is again not much more than a factory for RandomCharEnumerator. The interesting thing here is that it passes the set of characters to be used in the random generation to RandomCharEnumerator. The character sets are upper, lower, digit and special and are themselves statically defined but are composable  using a CharTypes enumeration.

Like FibonacciSequence, RandomCharSequence is an infinite set. You have to limit how much of it you grab at a particular time using the Take(int) extension method from System.Linq.

RandomCharSequence as Password Generator

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Collections;
using System.Security.Cryptography;
using System.Reflection;
using System.Collections.ObjectModel;

namespace NewPassword
{
    class Program
    {
        static void Main( string[] args )
        {
            int length = -1;
            int count  = -1;
            if( args.Length > 0 )
            { int.TryParse( args[0], out length ); }
            else
            { length = 8; }
            if( args.Length > 1 )
            { int.TryParse( args[1], out count ); }
            else
            { count = 5; }
            
            var pwdseq = new RandomCharSequence();
            for( int i = 0; i < count; i++ )
            {
                Console.WriteLine( pwdseq.Take( length ).ToArray() );
            }
        }
    }

    [Flags]
    public enum CharTypes
    {
        Lower   = 0x01,
        Upper   = 0x02,
        Digit   = 0x04,
        Special = 0x08,
        All     = Upper | Lower | Digit | Special
    }
    public class RandomCharSequence : IEnumerable<char>
    {
        static readonly IEnumerable<char> s_lower   = new[] { 'a', 'b', 'c', 'd', 'e', 'f', 'g', 'h', 'i', 'j', 'k', 'l', 'm', 'n', 'o', 'p', 'q', 'r', 's', 't', 'u', 'v', 'w', 'q', 'y', 'z' };
        static readonly IEnumerable<char> s_upper   = new[] { 'A', 'B', 'C', 'D', 'E', 'F', 'G', 'H', 'I', 'J', 'K', 'L', 'M', 'N', 'O', 'P', 'Q', 'R', 'S', 'T', 'U', 'V', 'W', 'Q', 'Y', 'Z' };
        static readonly IEnumerable<char> s_digit   = new[] { '0', '1', '2', '3', '4', '5', '6', '7', '8', '9' };
        static readonly IEnumerable<char> s_special = new[] { '!', '"', '#', '$', '%', '&', '\'', '(', ')', '*', '+', ',', '-', '.', '/', ':', ';', '<', '=', '>', '?', '@', '[', '\\', ']', '^', '_', '`', '{', '|', '}', '~' };

        //these static properties must exactly match the flags defined in the CharTypes enum
        private static IEnumerable<Char> Lower   { get{ return s_lower; } }
        private static IEnumerable<Char> Upper   { get{ return s_upper; } }
        private static IEnumerable<Char> Digit   { get{ return s_digit; } }
        private static IEnumerable<Char> Special { get{ return s_special; } }

        public RandomCharSequence() : this( CharTypes.All ){}
        public RandomCharSequence( CharTypes charTypes )
        {
            CharTypes = charTypes;
        }

        public CharTypes CharTypes {get; set;}

        public IEnumerator<char> GetEnumerator()
        {
            List<char> pool = new List<char>();
            foreach( var type in (CharTypes[])Enum.GetValues(typeof(CharTypes) ) )
            {
                //CharTypes.All is not a single bit flag. We don't want that one.
                if( type != CharTypes.All && (CharTypes & type) == type )
                {
                    //use reflection to add the static char list properties which
                    //match the flag bits.
                    pool.AddRange( 
                        (IEnumerable<char>)typeof(RandomCharSequence).GetProperty( 
                            type.ToString(), 
                            BindingFlags.Static | BindingFlags.NonPublic 
                            ).GetValue( this, null )
                        );
                }
            }
            return new RandomCharEnumerator( pool );
        }

        IEnumerator IEnumerable.GetEnumerator()
        {
            return GetEnumerator();
        }
    }

    public class RandomCharEnumerator : IEnumerator<char>
    {
        public RandomCharEnumerator( IList<char> pool )
        {
            Disposing = false;
            Pool      = new ReadOnlyCollection<char>( pool );
            Random    = RandomNumberGenerator.Create();
        }

        RandomNumberGenerator Random { get; set; } 
        public IList<char> Pool { get; private set; }
        int Index { get; set; }

        public char  Current
        {
            get { return Pool[Index]; }
        }
        object IEnumerator.Current { get { return Current; } }


        private bool Disposing{ get; set; }
        public void  Dispose()
        {
            //RandomNubmerGenerator only implements IDisposable as of .NET Framework 4.0
            IDisposable randDisposable = Random as IDisposable;
            if( randDisposable != null && !Disposing )
            {
                randDisposable.Dispose();
                Disposing = true;
            }
        }

        public bool  MoveNext()
        {
            Index = Random.GetInt( 0, Pool.Count );
            //infinite sequence of random chars. There's always a next one.
            return true;
        }

        public void  Reset(){ /* nothing */ }
    }

    public static class RandomNumberGeneratorExtension
    {
        public static int GetInt( this RandomNumberGenerator random, int min, int max )
        {
            if( min >= max )
                throw new InvalidOperationException( "The min value must be less than the max value." );
            byte[] buff = new byte[8];
            random.GetBytes(buff);
            long r = Math.Abs( BitConverter.ToInt64( buff, 0 ) );
            return (int)((long)min + (r % ((long)max - (long)min)));
        }
    }
}

Compile and run the program to pull some password strings out of the infinite random character sequence.

PS> csc -nologo -out:newpassword.exe ./Program.cs; ./newpassword 10 15
^mVhNjHdds
o4Eq=q;`es
%1R\rL3r3{
+PFRrl4e)u
TvAB+tjNu-
?8zCq~{?KB
@WY)+sF;^I
B+)'?sRee-
G'\e)QkjYp
L8(`@o};$$
)j`$7?RG)4
QcC{4;fZcb
_S89_tm]76
}kAiirj^!=
,qq|%-(s)@

Update: RandomNumberGenerator does not implement IDisposable until .Net Framework 4.0 so I needed to dynamically invoke the interface if present rather than statically compiling with Random.Dispose() in there.

Consider an array. First, you have to define its size which is fixed. Then you have to loop over the array and populate it with values. Then you can use it in some other loop later. Array is conducive to eager evaluation because you have to define its size in advance and you have to fill it up before you can use it. Lists are similar conceptually and are actually implemented with arrays internally. The main advantage of a list is that it is dynamically expandable.

IEnumerable is a very different thing. At its core IEnumerable is a contract to provide a factory for an IEnumerator<T> object. IEnumerator then just provides a mechanism to get the current element of the enumeration, move to the next element and reset. IEnumerator only has to know how to get the next element or start over. It doesn’t actually need a collection to exist. MoveNext() only has to get the next value. There’s no requirement that all values are known at any give time and there’s no requirement that the values are finite. This is the essence of lazy evaluation. Only enough work needs to be done to get the next answer. Nothing more.

Fibonacci: An infinite IEnumberable<T>

To illustrate that IEnumerable is a lazy evaluation pattern, I implemented the Fibonacci Sequence as an enumerable type in C#. I can pass a FibonacciSequence object to things that understand IEnumerable and it works. If IEnumerable were an eager implementation my code would spin in an infinite loop but it doesn’t because MoveNext() only calculates the next number in the series if it is asked.

using System;
using System.Collections;
using System.Collections.Generic;
using System.Linq;
using System.Numerics;

namespace LazyFibonacci
{
    class Program
    {
        static void Main( string[] args )
        {
            int i = -1;
            if( args.Length > 0 )
            { int.TryParse( args[0], out i ); }
            else
            { i = 100; }

            var fibonacci = new FibonacciSequence();
            /***
             * fibonacci is infinite.
             * Don't try operations that require the entire set to be enumerated:
             *  - fibinacci.ToList() --> NO!
             *  - fibonacci.Reverse() --> NO!
             *
             * Using .Skip(int) and .Take(int) is a good way to get slices of fibonacci, though.
             ***/

            foreach( var item in fibonacci.Take( i ) )
            {
                Console.WriteLine( item );
            }
        }
    }

    //FibonnacciSequence has no state.
    //It's just a factory for FibonacciEnumerator.
    public class FibonacciSequence : IEnumerable<BigInteger>
    {
        public IEnumerator<BigInteger> GetEnumerator()
        {
            return new FibonacciEnumerator();
        }

        IEnumerator IEnumerable.GetEnumerator()
        {
            return GetEnumerator();
        }
    }

    public class FibonacciEnumerator : IEnumerator<BigInteger>
    {
        public FibonacciEnumerator()
        {
            Reset();
        }

        BigInteger Last { get; set; }
        public BigInteger Current { get; private set; }
        object IEnumerator.Current { get { return Current; } }

        public void Dispose() { /*do nothing*/}

        public void Reset()
        {
            Current = -1;
        }

        public bool MoveNext()
        {
            if( Current == -1 )
            {
                //State after first call to MoveNext() before the first element is read
                //Fibonacci is defined to start with 0.
                Current = 0;
            }
            else if( Current == 0 )
            {
                //2nd element in the Fibonacci series is defined to be 1.
                Current = 1;
            }
            else
            {
                //Fibonacci infinite series algorithm.
                BigInteger next = Current + Last;
                Last = Current;
                Current = next;
            }
            //infinite series. there is always another.
            return true;
        }
    }
}

The moment of truth. If IEnumerable is lazy this will work.

PS> csc -nologo -r:System.Numerics.dll -out:fibonacci.exe ./program.cs
PS> $fib = (./fibonacci.exe 25); [string]::join(', ', $fib)
0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, 233, 377, 610, 987, 1597, 2584, 4181, 6765, 10946, 17711, 28657, 46368

Finally, with the forth part of the tutorial, I get to describe something that will make my PHP-coding reader want to use Haskell:  lazy evaluation.

But first, let’s go back to two different ways I’ve approached the problem of evaluating a keyboard input from a user in our rogue-like RPG game.    In tutorial #2, I created a function called move that used guards to discern what action to take based on a given input.    Here is move:

move :: Char -> String
move a
    |  a == 'w'       = "UP!"
    |  a == 's'       = "DOWN!"
    |  a == 'a'       = "LEFT!"
    |  a == 'd'       = "RIGHT!"
    |  otherwise      = "HANG AROUND AND DO NOTHING!"

In tutorial #3 I switched to a series of if / else if / else statements.

forever (do
    char <- getChar
    if char == 'q' then putStrLn "Thanks for Playing!"
         else if char == 'w' then up y >> output x >> output y
         else if char == 's' then down y >> output x >> output y
         else if char == 'a' then down x >> output x >> output y
         else if char == 'd' then up x >> output x >> output y
         else putStrLn "you did not type a correct entry")

This version had the additional side effect of requiring a manual escape of the compiler program in order to quit (something that is easily fixable, but still).    Now I have a new function ‘dashboard’ that uses lazy evaluation to compute values based on a given input.   Without beating around the bush, here it is:

dashboard :: Char -> MVar Int -> MVar Int -> IO ()
dashboard 'q' _ _ = exit "Thanks for Playing!"    // stop the program
dashboard 'w' x y = up y >> putStr " Coordinate: ( x = " >> output x >> putStr " , y = " >> output y >> putStr ")."
dashboard 's' x y = down y >> putStr " Coordinate: ( x = " >> output x >> putStr ", y = " >> output y >> putStr ")."
dashboard 'a' x y = down x >> putStr " Coordinate: ( x = " >> output x >> putStr ", y = " >> output y >> putStr ")."
dashboard 'd' x y = up x >> putStr " Coordinate:  ( x = " >> output x >> putStr ", y = " >> output y >> putStr ")."
dashboard w x y = putStr " Coordinate: ( x = " >> output x >> putStr ", y = " >> output y >> putStr ")."   // keep the Coordinate values the same

So, let’s think about our problem for a second.    So far, we have been focussed on getting our character to move around a map.    But what if we want to do something completely different, like say show an inventory list if the user hits ‘i’?    Or maybe cast a spell?     We could have a bunch of if – then statements or a whole bunch of guards, but it all could end up being a mess and impossible to read.

Fortunately, Haskell let’s you specify particular actions based on the constructors (entry values) for your function.    In the case above, dashboard accepts 3 values — one CHAR and two MVar Ints (ie. a mutable variable that has to be an integer — see the previous tutorial).   If the dashboard receives a ‘q’ for a value, it will say ‘thanks for playing’ and quit the program (the two ‘_’s mean it doesn’t matter what the values are that follow it).   The next entries do what we’ve come to expect -> change the value of the MVar based on the movement and then output the current coordinate’s status.    The last statement is a catch-all, asking Haskell to output the current spot.

Why might this way of doing things be better than using (say) guards?    Well, the first reason is that it gets to the point.    if the user hits ‘q’, Haskell will not attempt to evaluate any of the other function calls.   Admittedly, this function isn’t really helped performance-wise by lazy evaluation -> but what if moving in a certain direction (in the spot where a monster was) involved a long series of recursive computations.    We would not want Haskell to be using up its resources trying to figure out what it’s supposed to do when all the user wants to do is quit.

However, there’s still alot that could be added here.   What if we want to do something when the user hits ‘s’ and y is equal to zero.    Then we could do something like this:

dashboard 's' 0 y putStrLn "You are blocked and can go no further."  >> putStr " Coordinate:  ( x = " >> output x >> putStr ", y = " >> output y >> putStr ")."

Again, this can have really great performance benefits for your program.    If dashboard gets an ‘s’ and a ’0′, it will look no further and do the easy job of outputting the coordinate as is, rather than attempting to go through all kinds of irrelevant processes.   UPDATE:  Well, actually, this is all wrong.    Because ’0′ is not an MVAR.    Mind you, there is a way to get the function to accept two Ints instead and convert the MVAR to an Int for our purposes.    That’ll be another tutorial though.

The last benefit is that it gives a nice human-readable understanding of what happens when the function receives what, without a whole range of complex nested elements.

The downside, of course, is that because Haskell is type-safe, you must give this function a CHAR (not a Maybe Char, or a String) and two MVAR Ints (not an MVAR String or ordinary Int) or you will get a type error.       Things could also get more confusing if you decide that you want to return an IO (String) or other value instead of just outputting something to the screen.    But handling that problem might be for another tutorial.

I should, again, remind you that my up-to-date work on the rogue-like game called rasghiosse is available in a patch-tag repository.   Please feel free to add to it as you wish.

100.times do |iterador| #Equivalente ao "for" de outras linguagens
  n = fatorial(iterador)  #Calcula o fatorial
  if(iterador.even?)       #Se for um número PAR
    print "Resultado da operação: #{n}" #Imprime o resultado do fatorial
  end
end

Lembrando que Ruby não trabalha com Lazy Evaluation, portanto o código acima não seria adequado. Mas, digamos que a linguagem acima suporte Lazy Evaluation: o resultado de n só seria calculado se o iterador for par. Ou seja, embora estejamos sempre definindo que n = fatorial(iterador), o programa não calcula o resultado do fatorial até que precisemos dele - neste caso, até que ele seja impresso na tela. Ou seja, em linguagens como Haskell, que suportam Lazy Evaluation por padrão, o código acima seria perfeitamente válido e não seria ineficiente. Normalmente, quando você usa Lazy Evaluation o código que só rodará depois é chamado de "promisse", pois ele é uma promessa que o valor será calculado.
Mas porque isso é tão interessante?

Justamente, porque atrasar o cálculo de algo pode te dar maior fluidez em alguns outros momentos. Já citei anteriormente sobre o DataMapper, que na hora de fazer uma busca retorna apenas uma "promessa" que que irá buscar, e se você precisar apenas do primeiro elemento do Array ele buscará apenas o primeiro elemento. Também, no MongoParadigm (meu projeto de um mapeador para MongoDB) estou tentando deixá-lo Lazy, pois gostaria mesmo de aproveitar alguns conceitos do DataMapper para o Mongo. Mas esses dias, tive um problema diferente:
Estava trabalhando num passatempo, uma interface para listar os documentos do MongoDB. Estava usando Qt4, Ruby, e eu tinha uma coleção de documentos com 600 mil documentos (imagine 600 mil registros numa tabela, como comparação). O problema é que eu exibiria apenas um elemento por vez, e teriam dois botões (próximo e anterior), e não faria sentido nenhum ficar buscando os documentos sempre que eu apertasse em próximo ou anterior (afinal, é um projeto offline e eu queria fluidez total). Também, seria impossível buscar os 600 mil de uma vez e popular um Array com todos eles, afinal isso demoraria muito tempo e acabaria com a idéia de fluidez. Então, pensei em usar Threads, mas... Qt4 não suporta Threads do Ruby.
O que fazer? Aprender GTK para Ruby, e ter que lidar com uma mudança de quase todo o código? Mudar de linguagem? Achar um jeito de rodar Threads nativas em Ruby, e sabe-se lá como lidar com essa nova complexidade? usar um timer e ficar buscando de tempos em tempos novos objetos?
A solução foi razoavelmente simples: criar um "buscador", que mantém um registro de qual busca foi feita e do número de registros que a coleção possui. Criar um "Hash" para armazenar todos os registros, e a partir daí, sempre que um registro for requisitado, e se ele não existir no Hash, ele é buscado (junto com mais alguns registros à frente dele) e armazenado no hash. Desta forma, fica bem mais fluído e até mesmo é uma solução bem mais elegante do que o uso de Threads.
Mas... até quando usar Lazy Evaluation?
Note que não é uma "bala de prata", que nem todos os problemas são solucionado usando Lazy Evaluation. Algumas vezes, usar Lazy Evaluation mais atrapalha do que ajuda - especialmente nas linguagens como Ruby que não a suportam nativamente. Isso porque, algumas vezes, você soluciona um problema mas deixa seu programa mais difícil de entender, ou os erros não ficam muito visíveis.
Mais à frente, eu tento postar novidades sobre o assunto. Por hora, a interface gráfica está no meu GitHub, basta cloná-la e testá-la (note que você precisará do driver Mongo para Ruby e do Qt4).
]]>



http://xosfaere.wordpress.com/2009/06/30/navision-lazy-evaluation/
Tue, 30 Jun 2009 05:43:32 +0000
xosfaere
http://xosfaere.wordpress.com/2009/06/30/navision-lazy-evaluation/

Navision C/AL can be quite monotonous to develop in – which is also one of its strengths – strength through simplicity, but sometimes one simply desires some power tools to get past the endless repetitive boiler-plate code.

Microsoft .Net Framework, CLR, COM interop, C# and Lazy Evaluation (aka IEnumerable of T) to the rescue!
The example I’ll show here is probably not the best one. I’ll be showing how to lazily enumerate files on the file system. Navision already has a special virtual table called the file table that serves to enumerate over the file system. Nevertheless, this example will show what you can do, and maybe you’ll prefer my approach, although minimizing dependencies on automations is of course desirable.
So, let’s get started here.
First we define an Navision version of the IEnumerable interface. This is straight-forward and is immensely useful for iteroperability between Navision and automations. It provides a very smooth iteration idiom.
 


using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace Demo.IO
{
    using System.Runtime.InteropServices;

    [Guid("0BC2788B-A22E-4DF4-A04F-161E3A9EAFC4")]
    [ComVisible(true)]
    public interface ILinear
    {
        object Current { get; }

        bool MoveNext();

        void Reset();
    }
}


This simple interface provides a great deal of expressiveness due to its simplicity, generality and broad applicability.
In order to make use of this, an equal implementation class should be defined, it merely wraps around an IEnumerable<object>. This is left as an exercise for the reader.
Why IEnumerable of object you may ask? Because COM interop is not so happy about parametric polymorphism and generic types. That wohn’t be a problem in Navision though. The only problem is the limits around passing data to and from Navision where f.x. text is limited to 1024 characters. – But here you can again utilize the above type to indirectly pass around a large string wrapped in an ILinear.
Lazy Evaluation in C# 2.0 (yes, it’s so yesterday, but laziness never expires!) is our means to efficiently enumerate and traverse arbitrarily large file system trees. Here’s how it’s done.
 

        public ILinear GetFiles(string path, string pattern, bool recursive)
        {
            var result = (Linear)null;
            try
            {
                result = new Linear(LazyGetFiles(path, pattern, recursive));
            }
            catch (Exception) { }
            return result;
        }

I’ll not show the definition of LazyGetFiles here, but you can find the basic technique many places on the Web, e.g.

http://weblogs.asp.net/whaggard/archive/2004/08/15/214864.aspx
http://weblogs.asp.net/podwysocki/archive/2009/03/18/functional-net-laziness-becomes-you.aspx

I always wrap COM entry-points with exception handling to avoid crashing Navision should anything fail (using the most general exception class here). I found it a good practice to do this, in combination with access to the current exception state of the class, for logging unexpected run-time exceptions inside Navision.
It’s a bit painful to declare variables in Navision (you have to go through UI menus to do this, it’s not possible in pure text – although that may change in future versions of Navision) – the point of which is to say that if it were a bit less painful, maybe even with type-inference, one might instead return a Maybe value but we can use ISCLEAR from within Navision to detect null-values and therefore see if a failure occurred.
]]>



http://dutherenverseauborddelatable.wordpress.com/2008/05/18/batteries-included-lazy-lists-version-03/
Sun, 18 May 2008 18:40:52 +0000
yoric
http://dutherenverseauborddelatable.wordpress.com/2008/05/18/batteries-included-lazy-lists-version-03/

An updated version of the Lazy List module for OCaml has just been uploaded to Batteries Included and submitted to ExtLib. See the release notes for more details.

In addition, I am currently using this module to write a parser combinator library for OCaml. This library has reached early testing stage and will hopefully be added to Batteries Included soon.
]]>



http://dutherenverseauborddelatable.wordpress.com/2008/05/11/quelques-mots-de-programmation-paresseuse/
Sun, 11 May 2008 20:20:22 +0000
yoric
http://dutherenverseauborddelatable.wordpress.com/2008/05/11/quelques-mots-de-programmation-paresseuse/

Ces jours-ci, je travaille beaucoup avec et sur OCaml, que ce soit pour le projet ExtraPol (dont je finirai bien par vous glisser quelques mots) ou pour Batteries Included (la rénovation en cours de la bibliothèque standard de OCaml). En particulier, je viens de finaliser un module de gestion des listes paresseuses. Paresseuses ? Oui, paresseuses.

Attardons-nous un moment sur le concept de paresse en programmation.

En Java (ou C++ ou C# ou …)
Presque tous les langages de programmation permettent, de manière restreinte, de définir des expressions paresseuses, c’est-à-dire des expressions dont le résultat n’est calculé que s’il peut influencer l’exécution du programme. Ainsi, en Java, nous pourrons définir la méthode isEquals suivante :
bool isEquals(Object x)
{
  return x && x.equals(myObject);
}

Ici, au cours de l’exécution de cette fonction, x.equals(myObject) ne sera ffectivement évalué que si x n’est pas null. Java définit ainsi trois opérateurs paresseux &&, || et ?: : dans chacun des trois cas, à l’exécution du programme, la première opérande est évaluée avant de décider que faire de la deuxième (et de la troisième, dans le cas de ?:). Ces constructions sont très utiles, mais sont loin de couvrir toutes les circonstances dans lesquelles la paresse peut s’avérer utile.
Ainsi, imaginons un instant que nous souhaitons écrire une bibliothèque de journalisation, dont le rôle est d’enregistrer des messages dans un fichier au fur et à mesure de l’exécution du programme. Ajoutons une contrainte : les messages ne doivent être effectivement enregistrés que lorsque le journal est activé, par exemple parce que l’utilisateur est en mode de débogage :
void log(String s)
{
   if(LOG) stream.println(s);
}

La méthode log sera typiquement invoquée des centaines de fois durant l’exécution du code, sous la forme suivante :
void myFunction(int i, int j, int k)
{
   myLog.log("Entering myFunction("+i+", "+j+", "+j+")");
   //...
   myLog.log("Leaving myFunction()");
}

Des centaines de fois, nous aurons donc besoin de calculer le résultat de "Entering myFunction("+i+", "+j+", "+j+")", soit trois conversions d’entiers en chaînes de caractères, 6 concaténations de chaînes de caractères et un gaspillage de mémoire vive que nous pourrions éviter lorsque LOG est false. Comment faire pour éviter ce gaspillage ? La première possibilité consiste à exposer la valeur de LOG à tout le programme et à laisser le programmeur écrire plutôt
void myFunction(int i, int j, int k)
{
   if(LOG) myLog.log("Entering myFunction("+i+", "+j+", "+j+")");
   //...
   if(LOG) myLog.log("Leaving myFunction()");
}

Malheureusement, cette transformation nous oblige à contaminer tout le programme avec ce champ LOG, au détriment de la lisibilité et de l’extensibilité. En C ou C++, on pourrait cacher ce LOG derrière une macro, cette fois au détriment du débogage, de la modularité et de la robustesse. En Java, si nous n’avons pas une telle possibilité, nous pouvons utiliser des classes anonymes  pour arriver aux mêmes fins :
Commençons par modifier notre bibliothèque de journalisation :
public interface LazyString
{
   public String toString();
}

void log(Object s)
{
   if(LOG) stream.println(s.toString());
}

L’interface LazyString n’est guère contraignante : elle se contente de promettre que les objets qui l’implantent dispoent bien d’une méthode publique String toString(), qui servira à extraire de l’objet une chaîne de caractères. La différence avec ce qui précède est que nous pouvons nous débrouiller pour que la construction de la chaîne de caractères n’ait lieu qu’au moment où la méthode println est invoquée. En particulier, cette construction n’aura jamais lieu si LOG est false. Pour utiliser cette nouvelle version du journal, nous pourrons réécrire myFunction de la manière suivante :
void myFunction(int i, int j, int k)
{
   myLog.log(new LazyString() { public String toString() { return "Entering myFunction("+i+", "+j+", "+j+")" });
   //...
   myLog.log("Leaving myFunction()");
}

Est-ce la fin de l’histoire ? Pas tout à fait. Pour le moment, en Java, nous ne pouvons pas améliorer la syntaxe lors de l’appel de log — en tant que langage, Java est connu pour sa lourdeur syntaxique. En l’absence d’un préprocesseur digne de ce nom, nous ne pourrons rien faire de ce côté-là. Par contre, nous pouvons nous attaquer à un autre problème, qui se posera dès que nous serons confrontés à une méthode log à peine peu plus complexe :
void log(Object s)
{
   if(LOG_TO_FILE) file_stream.println(s.toString());
   if(LOG_TO_WINDOW) text_pane.out.println(s.toString());
   if(LOG_TO_STATUSBAR) statusbar.setText(s.toString());
}

Ici, s.toString() sera invoqué trois fois et calculera trois fois le même résultat. Pour un exemple aussi simple que le nôtre, ce n’est pas encore bien grave, mais on peut imaginer des contextes dans lesquels le calcul serait suffisamment long pour que ce délai soit inacceptable.
Qu’à cela ne tienne, il suffit de réécrire log de manière à retenir la valeur de s.toString(). Voire mieux, nous pouvons encapsuler tout ceci dans une classe plus générique :
public interface Result<T>
{
   public T getValue();
}
public abstract class Lazy<T>
{
   private boolean computed = false;
   private T value = null;
   /**
    * Proceeds to the actual computation.
    * This method will only be called once.
    */
   protected abstract T value();
   public final synchronized T getValue()
   {
      if(computed == false)
      {
        value       = value();
        computed = true;
      }
      return value;
   }
}

public abstract class LazyString extends Lazy<String>
{
   public String toString()
   {
      return this.getValue();
   }
}

En modifiant myFunction pour utiliser cette nouvelle version de LazyString, nous obtenons :
void myFunction(int i, int j, int k)
{
   myLog.log(new LazyString() { protected String value() { return "Entering myFunction("+i+", "+j+", "+j+")" });
   //...
   myLog.log("Leaving myFunction()");
}

Qu’avons-nous gagné ? Nous avons maintenant sous la main une interface Result<T> qui permet de représenter une opération. Si l’objet qui implante Result<T> est en fait un Lazy<T>, le calcul ne sera effectué que si son résultat est effectivement consulté. Si le résultat est consulté plusieurs fois (potentiellement par plusieurs threads différents), le calcul n’est toujours effectué qu’une seul fois.
Nous venons d’ajouter une dose d’évaluation paresseuse à Java.
Pour aller plus loin, regardons du côté de la programmation fonctionnelle — et des structures de données paresseuses.
Du côté de la programmation fonctionnelle
Commençons par réécrire en OCaml la première version de nos fonctions :
let log s = if should_log then output stream s

Nous venons de définir, comme en Java, une fonction nommée log, qui accepte comme paramètre un argument s — ici, une chaîne de caractères. Le contenu de la fonction log instruit d’écrire s sur un certain flux stream, si une certaine valeur booléenne should_log est vraie. Comme en Java, nous invoquerons cette fonction depuis my_function, à l’aide de :
let my_function i j k =
  log (sprintf "Entering my_function %i %i %i" i j k);
  (* ... *)
  log "Leaving my_function"

Jusque-là, à part les parenthèses et l’utilisation de la fonction sprintf, rien de bien différent. De nouveau, il est nécessaire de convertir i, j et k en chaînes de caractères et de procéder à quelques concaténations.
À partir d’ici, comme en Java, nous pouvons définir équivalent de Lazy<T>, que nous appellerions probablement 'a lazy, doté d’un constructeur qui acceptera en argument une fonction dont le résultat est un 'a, etc. La transformation de notre code pour convertir log en appel paresseux est globalement similaire à ce que nous ferions en Java. De fait, tout ceci n’est pas nécessaire puisque puisque la programmation paresseuse est en fait une primitive du langage. Le mot-clé lazy introduit une expression de type 'a Lazy.t, c’est-à-dire dont le résultat est de type 'a et ne sera calculé que s’il est nécessaire. La fonction force : 'a Lazy.t -> 'a permet alors de consulter le résultat d’une valeur ainsi mise en réserve, en la calculant au passage si nécessaire. De fait, notre version définitive ressemblera à
open Lazy
let log s =
  if should_log_1 then output stream_1 (force s);
  if should_log_2 then output stream_2 (force s);
  if should_log_3 then output stream_3 (force s)

let my_function i j k =
  log (lazy (sprintf "Entering my_function %i %i %i" i j k));
  (* ... *)
  log (lazy "Leaving my_function")

Notons au passage qu’il ne serait pas possible de réécrire directement lazy sous la forme d’une fonction OCaml. Pour réinventer lazy, il serait nécessaire de passer par Camlp4 ou d’accepter des notations légèrement plus lourdes.
Et alors ?
Il va falloir que je vous avoue quelque chose : je me moque complètement de la fonction log. Dans la programmation paresseuse, le plus intéressant, c’est bien les structures de données.
Tenez, en Java, nous pouvons très bien redéfinir la notion d’itérateurs de la manière suivante :
public interface MyIterator<T>
{
  public Lazy<MyIterator<T>> next();
  public T value;
}

Un itérateur est ici un objet capable de contenir une valeur… et de renvoyer un autre itérateur, qui représente la suite de l’itération. On écrira de même en OCaml :
type 'a my_iterator = Iterator of 'a * 'a my_iterator Lazy.t

Complétons cette définition pour nous autoriser à construire des itérations finies :
type 'a node =
 &#124; Nil
 &#124; Cons of 'a * 'a lazy_list
type 'a lazy_list = ('a node) Lazy.t

Nous venons de définir la notion de liste paresseuse. Une liste paresseuse est une valeur paresseuse qui, une fois évaluée, produit soit le résultat Nil (la liste vide), soit un résultat de la forme Cons(h, t) où h est une valeur et t est la suite de la liste paresseuse.
À partir de cette définition, nous pouvons construire une fonction range, qui servira à représenter un intervalle d’entiers :
let rec range i j =
 if i >= j then Nil
 else            range (i+1) j

Ainsi, en OCaml, range 0 100000 calculera les nombres 0, 1, …, 100000 au fur et à mesure qu’ils seront demandés.
À partir de là, nous pouvons définir les transformations habituelles sur les structures de données. Ainsi, pour convertir (paresseusement) une liste paresseuse en une autre, comme pour les listes habituelles, nous pouvons définir la fonction map :
let rec map f l = match force l with
  &#124; Nil            -> lazy Nil
  &#124; Cons (h,t) -> lazy Cons (f h, map f t)

Cette fonction map, qui sera l’un des premiers outils que nous placerons dans notre bibliothèque de gestion des listes paresseuses, applique une fonction successivement à chaque élément d’une liste paresseuse, de manière à obtenir une nouvelle liste paresseuse. Pour doubler tous les éléments de notre intervalle précédent, nous écrirons donc
map (( * ) 2) (range 0 100000)

De la même manière, nous pouvons définir le nécessaire pour filtrer les éléments d’une liste afin de n’en garder que ceux qui vérifient une propriété donnée, le tout sous la forme d’une fonction filter, qui rejoindra map dans notre bibliothèque standard.
let rec filter f l = match Lazy.force l with
  &#124; Nil -> lazy Nil
  &#124; Cons(h,t) -> lazy (Cons (f h, filter t))

Et à ce prix-là, définissons une fonction iter, tout aussi standard, qui nous permettra d’appliquer une fonction impérative à tous les éléments d’une liste paresseuse, de la même manière que la boucle for de Python ou la nouvelle boucle for de Java :
let rec iter f l = match force l with
  &#124; Nil            -> ()
  &#124; Cons (h,t) -> f h; iter t

En combinant tout ce qui précède, nous pouvons faire afficher les carrés parfaits de l’ensemble des nombres pairs des nombres de l’intervalle [0; 100000].
let is_square x =
  let y = int_of_float (sqrt (float_of_int x)) in
  x = y * y

iter print_int (filter is_square (map (( * ) 2) (range 0 100000)))

Comme la liste n’est consultée qu’une seule fois, grâce à la magie de la paresse et du ramasse-miettes, tout ceci se fera fait sans avoir à allouer la mémoire vive nécessaire pour retenir tous les entiers entre 0 et 100000.
Jusqu’ici, toutes les opérations que nous avons vues auraient pu être implantées, peut-être avec quelques difficultés, en utilisant des itérateurs ou des générateurs, tels que ceux que définissent les bibliothèques Java, C#, JavaScript, Python, OCaml etc. Tout comme les listes paresseuses, les itérateurs et générateurs permettent de représenter des suites d’informations qui ne seront effectivement calculées que lorsqu’elles seront effectivement consultées. Mais à la différence des listes paresseuses, les itérateurs/générateurs oublient les informations immédiatement après les avoir fournies. Si les itérateurs et générateurs sont très utiles — et probablement plus optimisés que les listes paresseuses pour les exemples précédents — leur champ d’application s’arrête dès que les données peuvent être utilisées plusieurs fois.
Ainsi, considérons l’une des applications majeures des itérateurs/générateurs et des listes paresseuses : l’analyse de langages, et plus particulièrement l’analyse lexicale et syntaxique d’un code source. Le plus fréquemment, on commence par considérer le fichier d’entrée comme un itérateur/générateur de caractères. Un filtre, l’analyseur lexical, s’applique alors à cet itérateur pour le transformer en itérateur de lexèmes — c’est le rôle d’outils tels que Lex, Flex ou, aussi surprenant que cela puisse paraître, Sax. Ce deuxième itérateur est alors consommé par un analyseur syntaxique, dont le rôle est de produire un arbre de syntaxe abstraite, qui représentera le code source en mémoire vive — c’est, cette fois, le rôle d’outils tels que Bison, Yacc ou DOM. Ces derniers, ainsi que [presque tous] leurs concurrents, consultent à l’avance k lexèmes depuis l’itérateur de lexème, pour un certain k fixé lors de la conception de l’analyseur, émettent des hypothèses en partant de ces k lexèmes, et ne peuvent pas revenir en arrière, en cas d’erreur, de plus de k pas. À l’inverse, et de manière très schématique, les combinateurs de parseurs construits sur des listes paresseuses, tels que Parsec (pour Haskell) ou PLC (pour OCaml), ne sont pas limités par ces k lexèmes d’avance, puisqu’ils peuvent à volonté revenir en arrière dans la liste. Un élément ne disparaît de la liste paresseuse que lorsque sa valeur ne peut plus influencer l’exécution du programme. Cette conception à base de listes paresseuses se paye en termes de performances et de consommation de mémoire mais offre beaucoup plus de flexibilité, notamment la possibilité de construire ou de modifier dynamiquement des analyseurs syntaxiques.
Avant de conclure sur la comparaison entre itérateurs et listes paresseuses, précisons brièvement qu’il est aisé de construire l’un par-dessus l’autre : un itérateur est une liste paresseuse qui oublie ses éléments au fur et à mesure qu’ils sont consommés, alors qu’une liste paresseuse est un itérateur qui retient ses éléments jusqu’à intervention du ramasse-miettes. Ainsi, dans la bibliothèque sur laquelle je travaille, la conversion d’une liste paresseuse en itération s’est écrite, jusqu’à une récente optimisation :
let enum l =
  let reference = ref l in
    Enum.from (fun () -> match next !reference with
			 &#124; Cons(x,t) -> reference := t; x
			 &#124; Nil          -> raise Enum.No_more_elements )

Dans cet extrait de code, nous commençons par déclarer une variable modifiable nommée reference et qui désignera initialement le premier élément de la liste. Nous définissons alors une fonction anonyme qui, lorsqu’elle sera appelée, renverra l’élément actuel désigné par reference, ou, si nous avons dépassé la fin de la liste, lancera une exception Enum.No_more_elements pour signaler que l’itérateur est terminé. La fonction Enum.from construit l’itérateur dont le comportement est donné par cette fonction.
À l’inverse, pour convertir un itérateur en liste paresseuse, nous employons la fonction suivante :
let of_enum e =
  let rec aux () =
    lazy (match Enum.get e with
      &#124;	Some x -> Cons (x, aux () )
      &#124; None    -> Nil )
  in aux ()

Dans l’extrait, nous commençons par définir une boucle que nous nommons aux et dons le contenu est paresseux. À chaque fois qu’un nouvel élément de la liste est consulté, nous consommons la valeur du prochain élément de notre itérateur. Si celui-ci existe, nous l’appelons x, et ce x constitue le prochain élément de notre liste, tandis que la suite de la liste sera donnée par le résultat de la prochaine invocation de la boucle aux. Dans le cas contraire, la liste est terminée.
Références :

Pour plus de détails sur la distinction entre générateurs, itérateurs et listes paresseuses, je vous invite à consulter Iterators: Signs of Weakness in Object-Oriented Languages, par Henry G. Baker.
Pour plus de détails sur le module de listes paresseuses de Batteries Included, le code source est disponible sur OCaml Forge. Le code source du module Enum, qui définit des itérateurs pour OCaml, est disponible avec le reste de la bibliothèque ExtLib, sur Google Code.
Pour plus de détails sur la programmation paresseuse en OCaml, le guide de référence est à votre disposition.
Enfin, rendons à César ce qui appartient à César. Si l’évaluation paresseuse vous intéresse, vous êtes vivement encouragés à vous informer sur le langage de programmation Haskell, dans lequel toutes les évaluations sont paresseuses par défaut.

]]>



http://dutherenverseauborddelatable.wordpress.com/2008/05/10/batteries-included-preview-lazy-lists/
Sat, 10 May 2008 20:17:47 +0000
yoric
http://dutherenverseauborddelatable.wordpress.com/2008/05/10/batteries-included-preview-lazy-lists/

A quick note to inform that I have made available the first preview of a  module for OCaml Batteries Included module: Lazy Lists for OCaml. This module adds the ability to manipulate lists composed of elements which are only computed whenever their value is first needed. In particular, such lists may be used as a more powerful replacement for streams — or to port interesting algorithms from Haskell.

Code may be found here.
]]>



http://obfuscatedcode.wordpress.com/2008/02/16/functional-pearl-trees/
Sun, 17 Feb 2008 03:31:40 +0000
dbueno
http://obfuscatedcode.wordpress.com/2008/02/16/functional-pearl-trees/

[This post is Literate Haskell.  If you copy the entire post into a file with a .lhs extension, you can load up that file in your favorite Haskell Interpreter, and it should work.  Then you can test the functions mentioned herein.]

Given a binary tree (you know, a thing that’s either a leaf with some data or two branches, both of which are binary trees), can you compute a new binary tree with exactly the same structure, but with every leaf’s value replaced by the minimum value in the tree?
If you’re a programmer, of course you can.  One simple pass to find the minimum value in the tree, and another to replace each leaf with the minimum value.  Here is the data type and an implementation of this idea in Haskell.

> data Tree a = Leaf a          -- The leaf holds data of any type.
>             | Branch (Tree a) (Tree a) deriving (Show)

> replaceMin2 t = let m = findMin t
>                 in propagate t m
>   where
>     findMin (Leaf m) = m
>     findMin (Branch left right) = findMin left `min` findMin right

>     propagate (Leaf _) m = Leaf m
>     propagate (Branch left right) m = Branch (propagate left m)
>                                              (propagate right m)


Simple, and clear.  Now, can you think of a way to do it in one pass?  You might consider making one pass in which (1) for each leaf, replace its value with a mutable cell that can hold a value, returning the value of the leaf, then (2) for each branch, recursively compute the min on the left and right.  At the end, you set the cell you gave to all the leaves to the value of the min you computed in this single pass, so that each leaf gets the value at once.
This is a good idea.  However, this will change the type of the new tree.  Instead of having a tree of integers, you’ll have a tree of cells-pointing-to-integers, and you’ll need another pass to get rid of them.
Here is a solution.  One pass.  Ponder it.

> replaceMin :: Tree Int -> Tree Int
> replaceMin t = let (t', m) = rpMin (t, m) in t'

> rpMin :: (Tree Int, Int) -> (Tree Int, Int)
> rpMin (Leaf a, m) = (Leaf m, a)
> rpMin (Branch l r, m) = let (l', ml) = rpMin (l, m)
>                             (r', mr) = rpMin (r, m)
>                    in (Branch l' r', ml `min` mr)


Note how in replaceMin the variable m is both bound to the result of calling rpMin and as an argument to rpMin.  Totally insane.
That Doesn’t Work
I know; I said the same thing.  The contract of rpMin is that it consumes a tuple of the tree and the actual minimum value of the tree (!), and returns (1) the tree with the minimum value stuck in the right places, and (2) the actual minimum value.  If you’re used to imperative languages, or even functional languages without having used lazy evaluation, this contract is utter and complete nonsense.  In fact, it is strong grounds for doubting a programmer’s competence.
The reason it is nonsense is because call-by-value parameter passing is most programmer’s default mindset.  When a function is applied to its arguments, those arguments are computed down to some value of the appropriate type, and only then is the function invoked.  This is the function application semantics of many programming languages, such as Java, C, Perl, etc.
The function replaceMin depends upon a strange and wonderful semantics called call-by-need semantics.  In call-by-need semantics, when a function is invoked, the arguments are not evaluated.  Only when, and if, the body of the function demands one of the arguments are they actually turned into a value.  This fact makes replaceMin possible.  Since nothing in rpMin actually tests the value of m (e.g. by comparing it to 0 or something), but simply uses it, we are allowed to refer to a value which cannot even by computed until rpMin is finished.
This means the algorithm given above essentially implements the cells idea suggested before, with at least two advantages: (1) it’s pure, meaning there is no way to step on our toes by assigning the wrong thing at the wrong time; (2) it really requires only one traversal, and doesn’t change the type of our function.  It computes a new Tree of ints, just like the old one.
Acknowledgements
The function replaceMin and helper comes from http://www.cse.ogi.edu/pacsoft/projects/rmb/, in particular under “Other Artifacts”, linked to by the bullet point, “Slides for a talk on the recursive do-notation.”  I have omitted a link to the PDF on purpose, so you’ll see all the cool stuff those people have done.
Update 18 Feb 2008. As one person mentioned in the comments, this is quite obviously call-by-need, not call-by-name, semantics.  I have changed it in the post to avoid further confusion.
]]>



http://zerogradient.wordpress.com/2007/12/07/functional-programming-on-net-part-2/
Fri, 07 Dec 2007 20:55:28 +0000
Deen
http://zerogradient.wordpress.com/2007/12/07/functional-programming-on-net-part-2/

So most who read this aught to know what a prime number is, a number whose only factors are one and itself. This post is not on primes but does use them in a simple program which uses a simple algorithm to factor any given number. Now, many of you should know the difficulty in factoring numbers and how much of current cryptographic techniques rely on how hard the problem is.  The program I wrote was written as a benchmark between the languages F# and Nemerle. Primarily as an “expressioning” benchmark and then as an aside a note on speed.

The task was to write a program which takes an unbounded positive integer and outputs a list that is the decomposition of the number into its prime factors. I decided to leverage laziness to allow me to write a flexible and short implementation. As I will get to later neither of these languages support laziness in the true sense and hence corecursion (in the sense of the dual of recursion) was unavailable, disallowing techniques such as a lazy sieve. Firstly the theory.
Theory
Given some number n, there exists primes  such that  and the product  is unique to n. This is known as the Fundamental Theorem of Arithmetic or the unique factorization theorem. I will leave the proof as an excercise to the reader. A way to get to this is to divide n by its smallest factor > 1. Store the factor and repeat on the quotient until we get to 1. Why the smallest factor? Because the smallest factor of n > 1 must be prime. Why?
Suppose that this was false and smallest factor or least divisor of n, say a, was composite. Then we would have that there exists some b and some c such that a = b * c and that b > 1 and b < a (we are working with positive integers so if b = 1 then c = a, remember that b and c < a). So b also divides n (consider n = a * d = b * c * d). But we stated earlier that a was the smallest divisor of n so by contradiction a must be prime.
So as an example we take n = 18.  we have a = 9 and d = 2. 3 divides 9 so it must divide 18 and 18 / 3 = 3 * 2. Now to continue. 
Suppose we keep n = 18. We know 3 is its least divisor and its prime. so p1 = 3. We do 18/3 = 6.

Next we find least divisor of 6 which is 2. so p2 = 2. Now we do 6/2 = 3. 3 is prime so 18 = 3 * 2 * 3.


So it seems to do this we need to know how to find the least divisor for a given number. Well we know that the least divisor of a number must always be prime. So if given n, to find ld of n we start from 2, check if n mod 2 = 0 and work up till we find a prime that divides n. So for 35 we’d go through 2, 3, and hit 5 as its least divisor. A way to stop unnecessary checks is to leverage the fact that if an integer n > 1 is not divisible by any primes < =  then n is prime.
Let n = (p)(a). Let us suppose that p is the least divisor of n, we know it must be prime. Now suppose p >  then a >  since p <= a (remember p is the smallest divisor). Then we have that  which is a contradiction since it says n  > n. So at least one of p or a must be less than . We know p <= a so we know that at least p < . This proves our proposition. Note also that since . We use that fact to lessen our checks.
The basic idea then is to define an infinite list of all natural numbers and the primes as those numbers which fail some primality test filtered out. We define that tests as any number which is its own least divisor. I will not explain the code in depth – there is plenty of documentation on both languages – this is mostly to show how easy it is to go from reasoning to implementation.
Implementation.
Below is the F# code which implements this functionality:
open System

module Primes_f = 
    let (+:) a alList = LazyList.cons a alList

    let Z3 : bigint LazyList = LazyList.unfold (fun x -> Some(x , x + 1I)) 3I 

    let rec least_denominator_byfactor l n = 
        match l with 
            LazyList.Cons(p,ps) -> if n % p = 0I then 
                                        p
                                   elif p * p > n then
                                        n
                                   else
                                        least_denominator_byfactor ps n  
                       
    let rec prime = function
        n when n  failwith "Not positive Int"
        &#124; n when n = 1I -> false
        &#124; n when n > 1I -> least_denominator n = n
        &#124; _ -> failwith "?"
        
    and primes =  2I +: (LazyList.filter prime Z3)

    and least_denominator n = least_denominator_byfactor primes n
    
    let rec factors = function
        n when n  failwith "Not positive Int"
        &#124; n when n = 1I -> []
        &#124; n when n > 1I -> let p = least_denominator n  
                           p :: (factors (n / p)) 
                           
        &#124; _ -> failwith "?"



To display: 
    let dtm = DateTime.Now
    print_any ("Time is: " ^ dtm.ToString() )
    
    //99999988888776655423101   //let z = factors 999988710I//999998888877665542310I    
    let rnd = Random()                                        
    
    let rec Generate tx l = 
        match tx with
            0 -> l
            &#124; _ -> let z = bigint.FromInt32 (rnd.Next(1000000,int.MaxValue))    
                   Generate (tx - 1) ( ( factors z )::l )
                                        
    let list_of_primefactors =  Generate 10000 []//factors 9876543210I  //3 mins 100,000 -  20sec 10,000 .05
    let dtm2 = DateTime.Now 
    let d = dtm2 - dtm
  
    let primes1 = List.filter (fun l -> if List.length l = 1 then true else false) (list_of_primefactors)
    
    let probprimes = System.Convert.ToDouble( (List.length primes1)) / 1000.0
    
    
    List.map (fun c -> print_any c ; System.Console.WriteLine ("") ) primes1   
    print_any probprimes
    //print_any list_of_primefactors      
       
    System.Console.Write ("\n\nTime is: " ^ dtm2.ToString() ^ " Took: " ^ d.ToString() ^ "\n" )  
    System.Console.ReadLine ()



The F# code was pretty straightforward to implement. The language remains quite functional and I had a lazy list data structure which allowed semi-corecursion via unfold. Now the Nemerle code. Because of its more object-centricism (not a critique) I had to approach how I arranged the code a bit differently.
  
module Number
    private least_denominator_byfactor(l : Primes,  n : decimal) : Decimal 
        def p =  l.prime
        
        if((p==3) && (n%2 == 0))            
            2m
        else    
            if(n % p == 0)  
                p
            else if(p * p > n)
                n
            else
                least_denominator_byfactor(l.next,n)          
            
    public least_denominator(n : Decimal) : Decimal 
        least_denominator_byfactor(Primes(3), n ) 
        
    public IsPrime(k: Decimal) : bool
        &#124; n when n  throw ex("Not positive")
        &#124; n when n == 1 => false
        &#124; n when n == 2 => true
        &#124; n when n % 2.0m == 0 => false
        &#124; n when n > 2 => (n == least_denominator(n))
   
    public next_prime (v : Decimal) : Decimal
        def ip = IsPrime(v + 1)
        match(ip) 
            &#124; true => v + 1
            &#124; false => next_prime(v + 1)
        
    public factors(number : Decimal) : list[Decimal]
            &#124; n when n  throw ex("Not Positive")
            &#124; n when n == 1 => []
            &#124; n when n > 1 => def p = least_denominator(n) ; p :: factors(n/p)          

class Primes
    public prime : Decimal
    public next : LazyValue [Primes]
            
    public this (p : Decimal) 
        prime = p
        next = lazy (Primes (Number.next_prime(p)))



To display:
  
module Program
    Main() : void
    
        def dtm = DateTime.Now 
        WriteLine($"Time now is: $dtm") 
                  // 9998876655423101
        //Test Nums: 99998877665542310
        def rnd = Random()
        
        def Generate(tx, l = [])
            match(tx)
                &#124; 0 => l 
                &#124; _ => Generate(tx - 1, Number.factors( rnd.Next(1000000, int.MaxValue) )::l) 
            
        def list_of_primefactors = Generate(152)//Number.factors(9766427) 
       
        def dtm2 = DateTime.Now       
        
        foreach(pfactors in list_of_primefactors)
            foreach(num in pfactors)
               Write($"$num &#124; ") 
            WriteLine("")       */
        
        WriteLine($"Time Now is: $dtm2, Took $(dtm2 - dtm)")
        ReadLine()

While for example in the F# code I had only functions and general functionality I had to package the code into appropriate classes in nemerle and to have behaviour sort of baked into those data types (for example I could not unfold into a generic list of primes, I had to build a next mechanism into the lazy prime class). The nemerle implementation (algorithim not language) is quite a bit less inefficient. But this is because I did not really redress the design to go with objects. For example in F# I could afford mutual recursion since F# has light weight <fast> functions and has the caveat that the lazy list caches its data.
In Nemerle the Primality check in IsPrime requires more and more objects to be created until the test is passed (note the circularity wher ld looks for a next prime which in turn calls ld to find if its prime) so it bogs down quite quickly. Indeed for small numbers (less than 10 digits) the performance is quite close – implying that the actual languages are not far apart in speed. Nonetheless the rate of increase in time usage for Nemerle is much steeper (by a factor of ~14 before change but dropping to near F#’s after for single iterations) than for F# due to the object thrashing I was doing. For example by merely injecting the following code
private ldf(k : decimal,n : decimal) : decimal
        match(k) 
            &#124; m when n % m == 0 => m
            &#124; m when m * m > n => n
            &#124; _ => ldf(k + 1, n) 

private ld(n : decimal) : decimal
        ldf(2,n)  
and replacing the appropriate function in IsPrime, factoring 99998877665542310 went from taking 25 seconds to 3 seconds. A similar injection to F# increased the speed from 2 seconds to 8. F# certainly benefits from the caching in its Lazy list implementation. Both languages are eagerly evaluated except in small localized places. In effect the evaluation is more delayed than it is lazy in the true sense that one would find in Haskell. Thus for example this:
let rec sieve function = LazyList.Cons(z, zs) -> z +: sieve (LazyList.filter (fun n ->  (n % z) <> 0I) zs 
would fail to terminate when given sieve Z3, while similar code in Haskell knows where to stop evaluation.
Speed
As Noted earlier the F# code was fairly fast (helped, I suspect because of it caching, thus larger numbers benefited from previous computations and in having to do less work. One can really tell over multiple iterations where past iterations aid future ones. For example it took 3 minutes to factor 100,000 numbers between, 1,000,000 and 2^32. While it takes 15 secs (down from ~ 60 secs) in Nemerle to factor 120 nums, it takes F# 3 secs. In the next post I will post on Visual Studio integration, some graphs and data and improvements in the arrangement of code and primality testing for Nemerle.
One note is that F# sometimes generates confusing error messages. This error was due to using an int in place of a bigint i.e. n % 0 vs n % 0I. Error 1 Type error in the use of the overloaded operator ‘( % )’. No operator ‘%’ (full name ‘op_Modulus’) supported by the type ‘bigint’ matches the argument types. See also C:\projects\prime\prime\prime.fs(12,23)-(12,24). See also . Note the nice type system at work =)
As well, sometimes when you dont define your pattern matching cases properly it fails to build yet gives no error. Still some ways to go before being commercial. But hope it doesnt sell out when it does.
Interestingly .NET had no built in arbitrary precision integer data type (had because they just put it in for 3.5). F# does but Nemerle had to use decimal. Note though that to change I but have to rename type annotations. The code is general. Excluding the modules and classes Nemerle code and F# are very much on par.
]]>



http://muharem.wordpress.com/2007/05/27/laziness-is-a-virtue-in-programming/
Sun, 27 May 2007 08:44:40 +0000
muharem
http://muharem.wordpress.com/2007/05/27/laziness-is-a-virtue-in-programming/

Introduction
One of the things I really appreciate about Python is that it allows me to explore different programming styles. When I started with Python (coming from a C/C++/Java background) I would mostly use procedural style constructs.
These days, however, I am usually inclining towards a more functional pogramming style.
One of the key books that swayed me towards the latter was Mark Pilgrim’s “Dive Into Python”, one of the best (technical) books I have read so far. If you haven’t come across it yet, you should definitely take a look at it.
Another Python gem you may want to check out while experimenting with functional programming ideas is the itertools module.
Example
In the brief section of code that follows below I am contrasting the procedural versus the functional pogramming style through an example in which I am interested in obtaining the first in a (potentially large) range of numbers whose 8th root is an integer.
  1 from math import (pow, modf)
  2 from itertools import dropwhile
  3 
  4 def calculate(x):
  5     """calculates the 8th root of the number 'x'"""
  6     return(pow(x, 0.125))
  7 
  8 def wanted(v):
  9     """integer check: returns 'True' if fractional part of a number is 0"""
 10     return(not modf(v)[0])
 11 
 12 def unwanted(v):
 13     """returns 'False' if fractional part of a number is > 0"""
 14     return(modf(v)[0])

The lines 16-25 show a procedural style function using a loop and related control flow constructs to get the job done.
 16 def proceduralStyle(f, t):
 17     """
 18     finds the first in the range of numbers [f..t[ whose 8th root is an
 19     integer; procedural style
 20     """
 21     for x in xrange(f, t):
 22         v = calculate(x)
 23         if wanted(v): break
 24     else: v = None
 25     return(v)

The functional style solution (see lines 27-34 below) uses the dropwhile() method (from the itertools module) to get rid of any unwanted initial values (line 32).
Please note also how a generator expression (as opposed to normal list comprehension) is used (on line 32) to achieve lazy evaluation behaviour.
The syntactical differences are minute (parentheses versus square brackets) but the effects are huge.
A normal list comprehension will construct the entire list (and perform any calculations needed in the process) before completing. A generator expression on the other hand is comparable to an iterator, values are returned in piecemeal fashion and calculations are performed only as needed.
 27 def functionalStyle(f, t):
 28     """
 29     finds the first in the range of numbers [f..t[ whose 8th root is an
 30     integer; functional style
 31     """
 32     r8iter = dropwhile(unwanted, (calculate(x) for x in xrange(f, t)))
 33     try: return(r8iter.next())
 34     except StopIteration: return(None)

Finally, by experimenting with the source code we can see that lazy evaluation is in effect for the functionalStyle() function. It returns straightaway with the result anticipated (256 is the first number in the range whose 8th root is an integer (2)).
  1 bbox33:published $ python
  2 Python 2.4.4 (#1, May 22 2007, 13:30:14)
  3 [GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin
  4 Type "help", "copyright", "credits" or "license" for more information.
  5  >>> import evaltest2
  6  >>> from time import asctime as t
  7  >>> print t(); evaltest2.functionalStyle(2, 50000000); print t()
  8 Sun May 27 10:33:18 2007
  9 2.0
 10 Sun May 27 10:33:18 2007
 11  >>> print t(); evaltest2.proceduralStyle(2, 50000000); print t()
 12 Sun May 27 10:33:30 2007
 13 2.0
 14 Sun May 27 10:33:30 2007

]]>