Referring to my post below, I was thinking about the algorithms that actually have practical usage in the field of web developing. I would really appreciate any help for pointing me towards some of the algorithms.

To call yourself even a programmer, the most important structure in programming you should know is the “loop”. Yes, some even go further and say that those who can use loops effeciently have the rights to call themselves programmers. But I am going ahead. Here are the basic list of algorithms that you should know how to implement:

1. Binary Search
2. Any sorting algorithm (such as mergsort, quicksort, heapsort etc.)
3. Union-Find (think about Social network and you will get the idea)
4. Encryption algorithm (RSA, DES, Blowfish or whatever you know)
5. Dijkstra’s algorithm (really useful in figuring out the shortest path)

Remember, master these basic algorithms and then step up to the advanced algorithms. Do you know why Google is famous? They are famous because they’ve invented a simple but elegant solution to searching. Clearly, the developers had to go through all the basic algorithms to create something so sophisticated.

In questo articolo viene descritto passo per passo l’algoritmo di Dijkstra, con relativi esempi per renderne più semplice la compresione . Per leggere tale articolo non serve nessuna base teorica in quanto tutto ciò che serve viene data nell’articolo, è comunque VIVAMENTE CONSIGLIATO approfondire le conoscenze teoriche.

Nel primo paragrafo vengono date le basi teoriche sui grafi, nel secondo basi teoriche sui cammini e sui cammini minimi e infine ( nel terzo paragrafo) vi è una completa analisi dell’algoritmo.

Scarica l’articolo

Commenti consigli e critiche sono vivamente accettati!

Erst einmal ein Nachtrag zu meinem letzten Beitrag: Auch in teutschen Landen tut sich etwas in Sachen Scala. Noch nicht erschienen ist das Praxisbuch Scala: Programmieren in Scala für Ein- und Umsteiger. In der deutschsprachigen Blogosphäre bin ich auf dieses Scala Blog gestoßen. Es gibt sicher noch mehr, aber bevor ich lang herumsuche, schreibe ich doch lieber selber etwas:

Hier einmal ein etwas längeres Beispiel, wie man Java nach Scala übersetzten (oder sollte ich sagen: “eindampfen”) kann. Als nichttriviales Beispiel habe ich mir Dijkstras Algorithmus ausgesucht, der die kürzesten Wege in einem Graphen sucht.

Schritt eins: Irgendwo Java-Code klauen, z.B. von Literate Programs – eine gute Seite, um mal etwas Beispielcode verschiedener Sprachen anzuschauen.

import java.util.PriorityQueue;
import java.util.List;
import java.util.ArrayList;
import java.util.Collections;

class Vertex implements Comparable<Vertex>
{
    public final String name;
    public Edge[] adjacencies;
    public double minDistance = Double.POSITIVE_INFINITY;
    public Vertex previous;
    public Vertex(String argName) { name = argName; }
    public String toString() { return name; }
    public int compareTo(Vertex other)
    {
        return Double.compare(minDistance, other.minDistance);
    }
}

class Edge
{
    public final Vertex target;
    public final double weight;
    public Edge(Vertex argTarget, double argWeight)
    { target = argTarget; weight = argWeight; }
}

public class Dijkstra
{
    public static void computePaths(Vertex source)
    {
        source.minDistance = 0.;
        PriorityQueue<Vertex> vertexQueue = new PriorityQueue<Vertex>();
	vertexQueue.add(source);
	while (!vertexQueue.isEmpty()) {
	    Vertex u = vertexQueue.poll();
            // Visit each edge exiting u
            for (Edge e : u.adjacencies)
            {
                Vertex v = e.target;
                double weight = e.weight;
                double distanceThroughU = u.minDistance + weight;
		if (distanceThroughU < v.minDistance) {
		    vertexQueue.remove(v);
		    v.minDistance = distanceThroughU ;
		    v.previous = u;
		    vertexQueue.add(v);
		}
            }
        }
    }

    public static List<Vertex> getShortestPathTo(Vertex target)
    {
        List<Vertex> path = new ArrayList<Vertex>();
        for (Vertex vertex = target; vertex != null; vertex = vertex.previous)
            path.add(vertex);

        Collections.reverse(path);
        return path;
    }

    public static void main(String[] args)
    {
        Vertex v0 = new Vertex("Harrisburg");
	Vertex v1 = new Vertex("Baltimore");
	Vertex v2 = new Vertex("Washington");
	Vertex v3 = new Vertex("Philadelphia");
	Vertex v4 = new Vertex("Binghamton");
	Vertex v5 = new Vertex("Allentown");
	Vertex v6 = new Vertex("New York");
	v0.adjacencies = new Edge[]{ new Edge(v1,  79.83),
	                             new Edge(v5,  81.15) };
	v1.adjacencies = new Edge[]{ new Edge(v0,  79.75),
	                             new Edge(v2,  39.42),
	                             new Edge(v3, 103.00) };
	v2.adjacencies = new Edge[]{ new Edge(v1,  38.65) };
	v3.adjacencies = new Edge[]{ new Edge(v1, 102.53),
	                             new Edge(v5,  61.44),
	                             new Edge(v6,  96.79) };
	v4.adjacencies = new Edge[]{ new Edge(v5, 133.04) };
	v5.adjacencies = new Edge[]{ new Edge(v0,  81.77),
	                             new Edge(v3,  62.05),
	                             new Edge(v4, 134.47),
	                             new Edge(v6,  91.63) };
	v6.adjacencies = new Edge[]{ new Edge(v3,  97.24),
	                             new Edge(v5,  87.94) };
	Vertex[] vertices = { v0, v1, v2, v3, v4, v5, v6 };

        computePaths(v0);
        for (Vertex v : vertices)
	{
	    System.out.println("Distance to " + v + ": " + v.minDistance);
	    List<Vertex> path = getShortestPathTo(v);
	    System.out.println("Path: " + path);
	}
    }
}

Das ist einigermaßen lesbarer Java-Code. Setzen wir das Ganze einmal möglichst 1:1 in “Besseres-Java-Scala” um:

object dijkstra {

    class Vertex(val name:String) extends Ordered[Vertex] {
        var adjacencies:Array[Edge] = _
        var minDistance = Double.MaxValue
        var previous: Vertex = _
        override def toString() = name
        def compare(other:Vertex) = Math.signum(minDistance - other.minDistance).toInt
    }

    case class Edge(target:Vertex, weight:Double)

    def computePaths(source: Vertex) {
        source.minDistance = 0.0
        var vertexQueue = new scala.collection.immutable.TreeSet[Vertex]
        vertexQueue += source

        while (!vertexQueue.isEmpty) {
            val u = vertexQueue.firstKey
            vertexQueue -= u
            // Visit each edge exiting u
            for (e <- u.adjacencies) {
                val v = e.target
                val weight = e.weight
                val distanceThroughU = u.minDistance + weight
		if (distanceThroughU < v.minDistance) {
		    vertexQueue -= v
		    v.minDistance = distanceThroughU
		    v.previous = u
		    vertexQueue += v
		}
            }
        }
    }

    def getShortestPathTo(target:Vertex):List[Vertex] = {
        var path = new scala.collection.mutable.ListBuffer[Vertex]
        var vertex = target
        while(vertex != null) {
            path + vertex
            vertex = vertex.previous
        }
        path.toList
    }

    def main(args: Array[String]) {
        val v0 = new Vertex("Harrisburg")
	val v1 = new Vertex("Baltimore")
	val v2 = new Vertex("Washington")
	val v3 = new Vertex("Philadelphia")
	val v4 = new Vertex("Binghamton")
	val v5 = new Vertex("Allentown")
	val v6 = new Vertex("New York")
	v0.adjacencies = Array(Edge(v1,  79.83),
	                       Edge(v5,  81.15))
	v1.adjacencies = Array(Edge(v0,  79.75),
	                       Edge(v2,  39.42),
	                       Edge(v3, 103.00))
	v2.adjacencies = Array(Edge(v1,  38.65))
	v3.adjacencies = Array(Edge(v1, 102.53),
	                       Edge(v5,  61.44),
	                       Edge(v6,  96.79))
	v4.adjacencies = Array(Edge(v5, 133.04))
	v5.adjacencies = Array(Edge(v0,  81.77),
	                       Edge(v3,  62.05),
	                       Edge(v4, 134.47),
	                       Edge(v6,  91.63))
	v6.adjacencies = Array(Edge(v3,  97.24),
	                       Edge(v5,  87.94))
	val vertices = Array(v0, v1, v2, v3, v4, v5, v6)
        computePaths(v0)
        for (v <- vertices) {
	    println("Distance to " + v + ": " + v.minDistance)
	    val path = getShortestPathTo(v)
	    println("Path: " + path)
	}
    }
}

Kein großer Unterschied, außer dass man die Edge-Klasse jetzt mit der Lupe suchen muss. Das TreeSet ist ein Kompromiss, weil ich bei Scala-Klassen bleiben wollte, Scalas PriorityQueue aber kein “freies” Löschen von Elementen unterstützt.
Schauen wir mal, wie das ganze etwas “idiomatischer” aussieht:

object dijkstra {

    class Vertex(val name:String) extends Ordered[Vertex] {
        var adjacencies = List[Edge]()
        def -> (e:Edge) = { adjacencies += e ; this}
        var minDistance = Double.MaxValue
        var previous: Option[Vertex] = None
        override def toString() = name
        def compare(other:Vertex) = Math.signum(minDistance - other.minDistance).toInt
    }

    case class Edge(target:Vertex, weight:Double)

    def computePaths(source: Vertex) {
        import scala.collection.immutable.TreeSet
        def loop(vertexQueue:TreeSet[Vertex]) {
            if (!vertexQueue.isEmpty) {
                val u = vertexQueue.firstKey
                // Visit each edge exiting u
                loop(u.adjacencies.foldLeft(vertexQueue - u){ (vq ,e) =>
                    val v = e.target
                    val distanceThroughU = u.minDistance + e.weight
                    if (distanceThroughU < v.minDistance) {
                        val vq1 = vq - v
                        v.minDistance = distanceThroughU
                        v.previous = Some(u)
                        vq1 + v
                    } else vq
                })
            }
        }
        source.minDistance = 0.0
        val vertexQueue = new TreeSet[Vertex]
        loop(vertexQueue + source)
    }

    def getShortestPathTo(target:Vertex) = {
        def path(target:Vertex):List[Vertex] = target :: target.previous.map(path).getOrElse(Nil)
        path(target).reverse
    }

    def main(args: Array[String]) {
        val v0 = new Vertex("Harrisburg")
	val v1 = new Vertex("Baltimore")
	val v2 = new Vertex("Washington")
	val v3 = new Vertex("Philadelphia")
	val v4 = new Vertex("Binghamton")
	val v5 = new Vertex("Allentown")
	val v6 = new Vertex("New York")
	v0 -> Edge(v1, 79.83) -> Edge(v5, 81.15)
	v1 -> Edge(v0, 79.75) -> Edge(v2, 39.42) -> Edge(v3, 103.00)
	v2 -> Edge(v1, 38.65)
        v3 -> Edge(v1, 102.53) -> Edge(v5, 61.44) -> Edge(v6, 96.79)
	v4 -> Edge(v5, 133.04)
        v5 -> Edge(v0, 81.77) -> Edge(v3, 62.05) -> Edge(v4, 134.47) -> Edge(v6, 91.63)
	v6 -> Edge(v3, 97.24) -> Edge(v5, 87.94)
	val vertices = Array(v0, v1, v2, v3, v4, v5, v6)
        computePaths(v0)
        for (v <- vertices) {
	    println("Distance to " + v + ": " + v.minDistance)
	    val path = getShortestPathTo(v)
	    println("Path: " + path)
	}
    }
}

Alle Null-Referenzen sind verschwunden, die Edge-Arrays in Vertex durch Listen ersetzt (die durch eine etwas bequemere Syntax zu füllen sind), das previous-Feld ist jetzt eine Option, was in getShortestPathTo ausgenutzt wird.

Am stärksten hat sich computePaths verändert: Die while-Schleife wurde durch ein rekursive Funktion ersetzt und die for-Schleife durch ein foldLeft. Beide Änderungen dienten dazu, auch die vertexQueue-Struktur unveränderlich zu machen (man kann erkennen, wie sie “durchgereicht” wird)

Vertex ist die einzige verbliebene veränderliche Struktur, aber um diese auch unveränderlich zu machen, ist etwas mehr Aufwand erforderlich. Das Problem ist nämlich, dass die Edges auf einen Vertex verweisen und Vertizes Edges haben. Diesen Teufelskreis kann man aber durchbrechen, indem man Vertex in einen “Identitätsteil” und einen “Datenteil” aufsplittet, und die Edges nur auf den Identitätsteil zeigen lässt.

Hier die “funktionale” Version:

object dijkstra {

    type Graph = Map[Vertex, Data]
    type VertexQueue = Map[Data, Vertex]

    case class Vertex(name:String) {
        def apply(graph:Graph) =
        graph.getOrElse(this, error("no data for vertex " + name))
        override def toString() = name
    }

    case class Data(adjacencies:List[Edge], minDistance:Double, previous:Option[Vertex])
    extends Ordered[Data] {
        def compare(other:Data) = Math.signum(minDistance - other.minDistance).toInt
        def this(adjacencies:Edge*) = this(adjacencies.toList, Double.MaxValue, None)
    }

    case class Edge(target:Vertex, weight:Double)

    def computePaths(graph:Graph, source: Vertex) = {
        def foldLoop(u:Data, vertexQueue:VertexQueue, graph:Graph) =
        u.adjacencies.foldLeft((vertexQueue - u, graph)){ (tuple, edge) =>
            val (vq, map) = tuple
            val v = edge.target
            val distanceThroughU = u.minDistance + edge.weight
            if (distanceThroughU < v(map).minDistance) {
                val data = v(map)
                val newData = Data(data.adjacencies, distanceThroughU, vertexQueue get u)
                (vq - data + newData -> v, map + v -> newData)
            } else (vq, map)
        }

        def loop(vertexQueue:VertexQueue, graph:Graph):Graph =
        vertexQueue.keys.find(_ => true) match {
            case Some(u) => val tuple = foldLoop(u, vertexQueue, graph)
                            loop(tuple._1, tuple._2)
            case None => graph
        }

        val data = source(graph)
        val newData = Data(data.adjacencies, 0.0, data.previous)
        val vertexQueue = new scala.collection.immutable.TreeMap[Data,Vertex]
        loop(vertexQueue + newData -> source, graph + source -> newData)
    }

    def getShortestPathTo(target:Vertex, graph:Graph) = {
        def path(t:Vertex):List[Vertex] = t :: t(graph).previous.map(path).getOrElse(Nil)
        path(target).reverse
    }

    def main(args: Array[String]) {
        val v = Array("Harrisburg", "Baltimore", "Washington", "Philadelphia",
                      "Binghamton", "Allentown","New York").map(Vertex(_))
        val startGraph =
        Map(v(0) -> new Data(Edge(v(1), 79.83), Edge(v(5), 81.15)),
            v(1) -> new Data(Edge(v(0), 79.75), Edge(v(2), 39.42), Edge(v(3), 103.00)),
            v(2) -> new Data(Edge(v(1), 38.65)),
            v(3) -> new Data(Edge(v(1), 102.53), Edge(v(5), 61.44), Edge(v(6), 96.79)),
            v(4) -> new Data(Edge(v(5), 133.04)),
            v(5) -> new Data(Edge(v(0), 81.77), Edge(v(3), 62.05), Edge(v(4), 134.47),
                             Edge(v(6), 91.63)),
            v(6) -> new Data(Edge(v(3), 97.24), Edge(v(5), 87.94)))
        val graph = computePaths(startGraph, v(0))

        for (vertex <- graph.keys) {
	    println("Distance to " + vertex + ": " + vertex(graph).minDistance)
	    val path = getShortestPathTo(vertex, graph)
	    println("Path: " + path)
	}
    }
}

Wie angekündigt habe ich von Vertex die Klasse Data abgeteilt. Der Graph (eine Map aus den Vertizes und ihren Daten) muss nun immer durchgereicht werden. Ein Problem ergab sich daraus, dass Vertex jetzt nicht mehr “vergleichbar” ist, da ja die Distanzen in der Data-Klasse gelandet sind. Zuerst habe ich versucht, das ganze mit impliziten Parametern hinzubiegen, aber nach einiger Überlegung habe ich mich entschieden, einfach die Data-Klasse sortierbar zu machen, und die PriorityQueue des Originals nicht mehr durch ein TreeSet, sondern eine TreeMap abzubilden – wobei diesmal Data auf Vertex zeigt (also genau umgekehrt wie in der Graph-Map). Da die beiden genannten Typen oft vorkamen, habe ich die Typ-Aliase “Graph” und “VertexQueue” eingeführt. Data als Schlüssel für eine Map zu verwenden ist übrigens nicht ganz unproblematisch: In größeren Graphen muss man aufpassen, dass zwei Data-Instanzen nicht als “gleich” angesehen werden, nur weil sie zufällig die gleichen Nachbarorte im gleichen Abstand haben.

Aus der inneren Funktion loop habe ich die Funktion foldLoop herausgebrochen, die die eigentliche Arbeit erledigt (wie foldLeft funktionert, hatte ich ja schon im Origami-Beitrag erklärt).

Vermutlich wird mein Programm keinen Schönheitspreis gewinnen, aber im Gegensatz zu den üblichen Beispielen zur funktionalen Programmierung (die oft wie Taschenspielertricks wirken) kann man hier sehen, wie es aus einem imperativen Programm Schritt für Schritt entstanden ist, und auch, welche Schwierigkeiten es dabei gab. Sicher könnte man das Programm weiter verbessern, aber dann müsste man stärker von der vorgegebenen Struktur abweichen und es wäre nicht mehr sinnvoll, es Seite an Seite neben das Java-Original zu stellen und zu vergleichen.

Dieser Code ist nur als “Demo” gedacht und ich vermute, dass er nicht besonders performant ist. Bei funktionaler Programmierung spielt die Auswahl der “richtigen” Datenstrukturen eine große Rolle, und diese sind hier sicher nicht optimal. Dabei ist es oft nicht die Geschwindigkeit, sondern der Speicherbedarf, der Probleme bereitet. Vermutlich sollte man sich erst einmal nach einer guten Graphen-Bibliothek umsehen, denn unveränderliche Datenstrukturen richtig zu schreiben ist nicht trivial.

Weiterhin sollte man in unserem Beispiel abwägen, ob man nicht lokal auch imperative Konstrukte zulassen sollte. “Imperativ” ist nicht gleich “schlecht”, schlecht sind vor allem Seiteneffekte und veränderliche Daten, die aus ihrer lokalen Umgebung “entkommen”, indem sie weitergereicht werden.

Schön, dass ihr bis hierhin durchgehalten habt. Und falls ihr mal dringend von Harrisburg nach Allentown müsst: Jetzt kennt ihr den kürzesten Weg!

Minh họa cho vui

Sau đây mình xin giới thiệu tới các bạn 3 bài toán quy hoạch động khá thú vị. Thú vị ở  chỗ chúng có đề bài rất giống nhau, chỉ  khác ở chỗ rất nhỏ nhưng lại làm cho chúng có mức độ  khó tăng dần. Thực ra thì cũng không có gì lắm, nhưng dẫu sao cũng mời các bạn cùng “thưởng thức” :

Bài toán 1:

Cho ma trận A kích cỡ M*N (1<=M,N<=100, M dòng, N cột).Mỗi ô của ma trận có một giá trị nguyên nằm trong khoảng 1..100. Từ  mỗi ô (I,J) (I: chỉ số cột, J: chỉ số dòng) có thể đến được các ô sau (nếu có):  (I+1,J-1), (I+1,J), (I+1,J+1).

Hãy tìm một đường đi xuất phát từ ô bất kì của cột 1 và kết thúc tại ô bất kì của cột N sao cho tổng giá trị của các ô đi qua trên đường đi là nhỏ nhất.

>>Thuật giải: Không cần bàn nhiểu ta cũng thấy ngay được công thức quy hoạch động của bài này. Gọi Fx[I,J] là tổng giá trị nhỏ nhất để đi từ  một ô bất kì của cột 1 đến ô (I,J). Khi đó:

F[1,J]=A[1,J] (1<=J<=M)

F[I,J]=Min(F[I-1,J-1],F[I-1,J],F[I-1,J+1])+A[I,J] (2<=I<=N,1<=J<=M)

Truy vết in ra đường đi cũng không có gì khó khắn lắm

Bài toán 2: Tương tự  như  bài toán 1 nhưng  ô (I,J) có thể đến các ô sau: (I,J+1), (I,J-1), (I+1,J)

Khá là vấn đề khi áp dụng QHĐ do một ô có thể được đến từ  một ô khác ở cột liền trước bên trái hoặc một ô liền trên hoặc một ô liền dưới. Ở bài toán trên ta tính Fx lần lượt từ  cột 1 đến cột N do kết quả mỗi cột chỉ phụ thuộc vào cột trước nó đằng này bài 2 chúng ta bị ép 3 phía như thế ta không biết sẽ phải tính toán Fx theo thứ  tự  như  thế nào :-S Các của mình đưa ra là QHĐ kết hợp thêm chút ít “thủ công”

>>Thuật giải: Ta cũng thiết kế một mảng Fx[I,J] chức năng như  trên nhưng ta sẽ tính theo một cách khác. Đầu tiên cũng sẽ là gán F[1,J]:=A[1,J] với 1<=J<=M. Với mỗi ô (I,J) ta nhận thấy trên đường đi nhỏ nhất dẫn đến nó thì sẽ có một ô (I-1,X) để từ  ô (I-1,X) chuyển sang ô (I,X) rồi đi đến nó. Chỉ cần xác định được ô (I-1,X) tính được Fx[I,J]. Mà 1<=X<=M nên ta sẽ thử  lần lượt X từ 1 đến M rồi tìm Min. Khi tìm được ta nên lưu lại giá trị của X cho mỗi ô (I,J) để tiện cho việc truy vết. Sau đây là mã nguồn mình cài đặt cho thuật toán này:

Uses Crt;
Var Map:Array[1..100,1..100] Of Byte;
Rs:Array[1..100,1..100] Of Record {chính là mảng Fx, với value là giá trị nhỏ nhất còn Back là X)
Back:Byte;
Value:Longint;
End;
M,N,i,j:Byte;
{—————————–}
Procedure ReadDT;
Var I,J:Integer;
F:text;
Begin
assign(f,’fi.inp’);reset(F);
Readln(F,M,N);
For J:=1 To M Do
Begin
For I:=1 To N Do Read(f,Map[I,J]);
Readln(F);
End;
End;
{——————————–}
Function GetRs(X,Y,Back:Byte):Longint; (Tính xem giá trị của đường đi tới ô (X,Y) nếu X=Back)
Var S:Longint;
I:Byte;
Begin
S:=Map[X,Y]+Rs[X-1,Back].Value;
For I:=Back To Y-1 Do Inc(S,Map[X,I]);
For I:=Y+1 To Back Do Inc(S,Map[X,I]);
GetRs:=S;
End;
{——————————–}
Procedure GenRsTable; (tạo bảng giá trị (mảng Rs))
Var Back,I,J:Byte;
S:Longint;
Begin
For J:=1 To M Do Rs[1,J].Value:=Map[1,J];
For I:=2 To N Do
For J:=1 To M Do
Begin
Rs[I,J].Value:=GetRs(I,J,1);
Rs[I,J].Back:=1;
For Back:=2 To M Do
Begin
S:=GetRs(I,J,Back);
If S<Rs[I,J].Value Then
Begin
Rs[I,J].Value:=S;
Rs[I,J].Back:=Back;
End;
End;
End;
End;
{——————————–}
Procedure OutIJ(X,Y:Byte);
Var I:Byte;
Begin
If X=1 Then
Begin
Writeln(X,’ ‘,Y);
Exit;
End;
OutIJ(X-1,Rs[X,Y].Back);
For I:=Rs[X,Y].Back To Y-1 Do Writeln(X,’ ‘,I);
For I:=Rs[X,Y].Back DownTo Y+1 Do Writeln(X,’ ‘,I);
Writeln(X,’ ‘,Y);
End;
{——————————–}
Procedure WriteRs;
Var I,J,JMin:Byte;
SMin:Longint;
Begin
SMin:=Rs[N,1].Value;
JMin:=1;
For J:=1 To M Do
If Rs[N,J].Value<SMin Then Begin
SMin:=Rs[N,J].Value;
JMin:=J;
End;
Writeln(SMin);
OutIJ(N,JMin);
End;
{——————————–}
Begin
Clrscr;
ReadDT;
GenRsTable;
writeRs;
readln;
End.

3. Bài toán 3: Tương tự  như  bài toán 1 nhưng  ô (I,J) có thể đến các ô sau: (I,J+1), (I,J-1), (I+1,J), (I-1,J)

Lần này bị o ép từ 4 phía thì có vẻ như  quy hoạch động khá khó khăn.

>>Thuật giải: Coi mỗi ô của ma trận như  một đỉnh của đồ thị. Áp dụng dijkstral. Lưu ý chương trình của mình của mình không sử  dụng mạng hai chiều mà “dãn” ra thành mảng 1 chiểu. Hàm Conv(X,Y:Byte) cho vị trí ô (X,Y) trong mảng một chiều.

Var P,Map:Array[1..100*100] Of Byte;
L,R:Array[1..100*100] Of Integer;
M,N:Byte;
C,First,Last:Integer;
{——————-}
Function Conv(X,Y:Byte):Integer;
Begin
Conv:=Y*N-N+X;
End;
{——————–}
Procedure ReadDt;
Var I,J:Byte;
Begin
Readln(M,N);
For J:=1 To M Do
For I:=1 To N Do Read(Map[Conv(I,J)]);
End;
{——————}
Procedure Add(Id:Integer);
Begin
If Last=100*100 Then Last:=1 Else Inc(Last);
L[Last]:=Id;
Inc(C);
End;
{——————}
Function Pop:Integer;
Begin
Pop:=L[First];
If First=100*100 Then First:=1 Else Inc(First);
Dec(C);
End;
{——————-}
Procedure Proc(Id:Integer);
Var X,Y:Byte;
Begin
X:=Id Mod N; If X=0 Then X:=N;
Y:=Id Div N; If X<>N Then Inc(Y);
If X<N Then
If (R[Conv(X+1,Y)]>(Map[Conv(X+1,Y)]+R[ID]))Or(R[Conv(X+1,Y)]=0) Then
Begin
R[Conv(X+1,Y)]:=Map[Conv(X+1,Y)]+R[Id];
P[Conv(X+1,Y)]:=Id;
Add(Conv(X+1,Y));
End;
{”””””””}
If X>1 Then
If (R[Conv(X-1,Y)]>(Map[Conv(X-1,Y)]+R[Id]))Or(R[Conv(X-1,Y)]=0) Then
Begin
R[Conv(X-1,Y)]:=Map[Conv(X-1,Y)]+R[Id];
P[Conv(X-1,Y)]:=Id;
Add(Conv(X-1,Y));
End;
{”””””””}
If (Y<M)And(X<>1)And(X<>N) Then
If (R[Conv(X,Y+1)]>(Map[Conv(X,Y+1)]+R[Id]))Or(R[Conv(X,Y+1)]=0) Then
Begin
R[Conv(X,Y+1)]:=(Map[Conv(X,Y+1)]+R[Id]);
P[Conv(X,Y+1)]:=Id;
Add(Conv(X,Y+1));
End;
{”””””””}
If (Y>1)And(X<>1)And(X<>N) Then
If (R[Conv(X,Y-1)]>(Map[Conv(X,Y-1)]+R[Id]))Or(R[Conv(X,Y-1)]=0) Then
Begin
R[Conv(X,Y-1)]:=(Map[Conv(X,Y-1)]+R[Id]);
P[Conv(X,Y-1)]:=Id;
Add(Conv(X,Y-1));
End;

End;
{——————-}
Procedure OutRs;
Procedure DQ(Id:Integer);
Var X,Y:Byte;
Begin
X:=Id Mod N; If X=0 Then X:=N;
Y:=Id Div N; If X<>N Then Inc(Y);
If P[Id]=0 Then
Begin
Writeln(Y,’ ‘,X);
Exit;
End;
DQ(P[Id]);
Writeln(Y,’ ‘,X);
End;
{—————}
Var Min,PMin:Integer;
X,Y:Byte;
Begin
Min:=R[Conv(N,1)];
PMin:=Conv(N,1);
For Y:=2 To M Do
If R[Conv(N,Y)]<Min Then
Begin
Min:=R[Conv(N,Y)];
PMin:=Conv(N,Y);
End;
Writeln(Min);
DQ(PMin);
End;
{——————-}
Procedure GenRs;
Var I:Byte;
Begin
Last:=0;First:=1;
FillChar(R,SizeOf(R),0);
FillChar(P,SizeOf(P),0);
C:=0;
For I:=1 To M Do
Begin
Add(Conv(1,I));
R[Conv(1,I)]:=Map[Conv(1,I)];
End;
While C<>0 Do Proc(Pop);
End;
{——————-}
Begin
ReadDT;
GenRs;
OutRs;
End.

Lưu ý cấu trúc file Input:

- Dòng đầu: M và N

- M dòng sau mỗi dòng là N số nguyên tương ứng với giá trị của ô (I,J)

1. Nhắc lại thuật toán Dijkstra tìm đường đi ngắn nhất
Bài toán: Cho đồ thị có hướng với trọng số các cung (i,j) là C[i,j] không âm, tìm đường đi ngắn nhất từ đỉnh s đến đỉnh t.
Thuật toán Dijkstra:
Bước 1- Khởi trị:
- Khởi trị nhãn đường đi ngắn nhất từ đỉnh s tới đỉnh i là d[i]:= C[s,i] (nếu không có đường đi trực tiếp từ s đến i thì C[s,i] bằng vô cùng). Lưu lại đỉnh trước khi tới i trên hành trình ngắn nhất là Tr[i] := s
- Khởi trị nhãn đỉnh s là d[s] =0
- Đánh dấu mọi đỉnh i là tự do (nhãn d[i] chưa tối ưu): DX[i]:=false
Bước 2 (vòng lặp vô hạn):
- Tìm đỉnh i₀ tự do có nhãn d[i₀] nhỏ nhất.
- Nếu không tìm được i₀ (i₀ =0) hoặc i₀ =t thì thoát khỏi vòng lặp còn không thì
+ Đánh dấu i₀ đã được cố định nhãn DX[i₀]:=True (gọi i₀ là đỉnh được cố định nhãn)
+ Sửa nhãn cho các đỉnh j tự do kề với i₀ theo công thức d[j] = Min{d[j], d[i₀]+C[i₀,j] và ghi lưu lại đỉnh trước j là i₀: Tr[j]:= i₀
Bước 3 &minus Tìm và ghi kết quả:
Dựa vào giá trị d[t] và mảng Tr để kết luận thích hợp

2. Cấu trúc Heap và một số phép xử lí trên Heap
a) Mô tả Heap: Heap được mô tả như một cây nhị phân có cấu trúc sao cho giá trị khoá ở mỗi nút không vượt quá giá trị khoá của hai nút con của nó (suy ra giá trị khoá tại gốc Heap là nhỏ nhất).
b) Hai phép xử lí trên Heap

- Phép cập nhật Heap
Vấn đề: Giả sử nút v có giá trị khoá nhỏ đi, cần chuyển nút v đến vị trí mới trên Heap để bảo toàn cấu trúc Heap
Giải quyết:
+ Nếu nút v chưa có trong Heap thì tạo thêm nút v thành nút cuối cùng của Heap (hình 1)
+ Chuyển nút v từ vị trí hiện tại đến vị trí thích hợp bằng cách tìm đường đi ngược từ vị trí hiện tại của v về phía gốc qua các nút cha có giá trị khoá lớn hơn giá trị khoá của v. Trên đường đi ấy dồn nút cha xuống nút con, nút cha cuối cùng chính là vị trí mới
của nút v (hình 2).

Chú ý: trên cây nhị phân, nếu đánh số các nút từ gốc đến lá và từ con trái sang con phải thì dễ thấy: khi biết số hiệu của nút cha là i có thể suy ra số hiệu hai nút con là 2*i và 2*i+1, ngược lại số hiệu nút con là j thì số hiệu nút cha là j div 2.

- Phép loại bỏ gốc của Heap
Vấn đề: Giả sử cần loại bỏ nút gốc khỏi Heap, hãy sắp xếp lại Heap (gọi là phép vun đống)
Giải quyết:
+ Tìm đường đi từ gốc về phía lá, đi qua các nút con có giá trị khoá nhỏ hơn trong hai nút con cho đến khi gặp lá.
+ Trên dọc đường đi ấy, kéo nút con lên vị trí nút cha của nó.
Ví dụ trong hình vẽ 2 nếu bỏ nút gốc có khoá bằng 1, ta sẽ kéo nút con lên vị trí nút cha trên đường đi qua các nút có giá trị khoá là 1, 2, 6, 8 và Heap mới như hình 3

3. Thuật toán Dijkstra tổ chức trên cấu trúc Heap (tạm kí hiệu là Dijkstra_Heap)
Tổ chức Heap: Heap gồm các nút là các đỉnh i tự do (chưa cố định nhãn đường đi ngắn nhất), với khoá là nhãn đường đi ngắn nhất từ s đến i là d[i]. Nút gốc chính là đỉnh tự do có nhãn d[i] nhỏ nhất. Mỗi lần lấy nút gốc ra để cố định nhãn của nó và sửa nhãn cho các đỉnh tự do khác thì phải thức hiện hai loại xử lí Heap đã nêu (phép cập nhật và phép loại bỏ gốc).

Vậy thuật toán Dijkstra tổ chức trên Heap như sau:
Cập nhật nút 1 của Heap (tương ứng với nút s có giá trị khoá bằng 0)
Vòng lặp cho đến khi Heap rỗng (không còn nút nào)
Begin
+ Lấy đỉnh u tại nút gốc của Heap (phép loại bỏ gốc Heap)
+ Nếu u= t thì thoát khỏi vòng lặp
+ Đánh dấu u là đỉnh đã được cố định nhãn
+ Duyệt danh sách cung kề tìm các cung có đỉnh đầu bằng u, đỉnh cuối là v
Nếu v là đỉnh tự do và d[v] > d[u] + khoảng cách (u,v) thì
Begin
Sửa nhãn cho v và ghi nhận đỉnh trước v là u
Trên Heap, cập nhật lại nút tương ứng với đỉnh v.
End;
End;

4. Đánh giá
+ Thuật toán Dijkstra tổ chức như nêu ở mục 1. Có độ phức tạp thuật toán là O(N²), nên không thể thực hiện trên đồ thị có nhiều đỉnh.
+ Các phép xử lí Heap đã nêu (cập nhật Heap và loại bỏ gốc Heap) cần thực hiện không quá 2.lgM phép so sánh (nếu Heap có M nút). Số M tối đa là N (số đỉnh của đồ thị) và ngày càng nhỏ dần (tới 0). Ngoài ra, nếu đồ thị thưa (số cung ít) thì thao tác tìm đỉnh v kề với đỉnh u là không đáng kể khi ta tổ chức danh sách các cung kề này theo từng đoạn có đỉnh đầu giống nhau (dạng Forward Star). Do đó trên đồ thị thưa, độ phức tạp của Dijkstra_Heap có thể đạt tới O(N. k.lgN) trong đó k không đáng kể so với N
+ Kết luận: Trên đồ thị nhiều đỉnh ít cung thì Dijkstra_Heap là thực hiện được trong thời gian có thể chấp nhận.

5. Chương trình

uses crt;
const maxN = 5001;
maxM = 10001;
maxC = 1000000000;
fi = &rquo;minpath.in&rquo;;
fo = &rquo;minpath.out&rquo;;

type k1 = array[1..maxM] of integer;
k2 = array[1..maxM] of longint;

k3 = array[1..maxN] of integer;
k4 = array[1..maxN] of longint;
k5 = array[1..maxN] of boolean;

var ke : ^k1; {danh sách đỉnh kề}
c : ^k2; {trọng số cung tương ứng với danh sách kề}
p : ^k3; 1 {vị trí đỉnh kề trong danh sách kề}
d : k4; {nhãn đường đi ngắn nhất trong thuật toán Dijkstra}
tr : k3; {lưu đỉnh trước của các đỉnh trong hành trình ngắn nhất }
dx : k5; {đánh dấu nhãn đã cố định, không sửa nũă}
h, {heap (Đống)}
sh : k3; {số hiệu của nút trong heap}
n,m,s,t, {số đỉnh, số cạnh, đính xuất phát và đỉnh đích}
shmax : integer; {số nút max trên heap}

procedure doc_inp;
var i,u,v,x : integer;
f : text;
begin
assign(f,fi);

{Đọc file input lần thứ nhất}

reset(f);
readln(f,n,m,s,t);
new(p);
new(ke);
new(c);
fillchar(p^,sizeof(p^),0);
for i:=1 to m do
begin
readln(f,u);
inc(p^[u]); {p^[u] số lượng đỉnh kề với đỉnh u}
end;
for i:=2 to n do
p^[i] := p^[i] + p^[i-1]; {p[i]^ dùng để xây dựng chỉ số của mảng kê}
close(f); {p[i]^ là vị trí cuối cùng của đỉnh kề với đỉnh i trong mảng kê}

{Đọc file input lần thứ hai}
reset(f);
readln(f);
for i:=1 to m do
begin
readln(f,u,v,x);
kê[p^[u]] := v; {xác nhận kề với đỉnh u là đỉnh v}
c^[p^[u]] := x; {xác nhận trọng số của cung (u,v) là x}
dec(p^[u]); {chuyển về vị trí của đỉnh kề tiếp theo của u}
end;
p^[n+1] := m; {hàng rào}
close(f);
end;

procedure khoitri;
var i : integer;
begin
for i:=1 to n do d[i] := maxC; {nhãn độ dài đường đi ngắn nhất từ s tới i là vô cùng}
d[s] := 0; {nhãn độ dài đường đi ngắn nhất từ s tới s là 0}
fillchar(dx,sizeof(dx),False); {khởi trị mảng đánh dấu: mọi đỉnh chưa cố định nhãn }
fillchar(sh,sizeof(sh),0); {khởi trị số hiệu các nút của Heap là 0}
shmax := 0; {khởi trị số nút của heap là 0}
end;

procedure capnhat(v : integer);
{đỉnh v vừa nhận giá trị mới là d[v], do đó cần xếp lại vị trí của đỉnh v trong heap, bảo đảm tính chất heap}

var cha,con : integer;
begin
con := sh[v]; {con là số hiệu nút hiện tại của v}
if con=0 then {v chưa có trong heap, thì bổ sung vào nút cuối cùng của heap}
begin
inc(shmax);
con := shmax;
end;
cha := con div 2; {cha là số hiệu hiện tại của nút cha của nút v hiện tại}
while (cha>0) and (d[h[cha]] > d[v]) do
{nếu nhãn của nút cha (có số hiệu là cha) lớn hơn nhãn của nút v thì đưa dần nút v về phía gốc tới vị trí thoả mãn điều kiện của heap bằng cách: kéo nút cha xuống vị trí của nút con của nó }
begin
h[con] := h[cha];
sh[h[con]] := con;
con := cha;
cha := con div 2;
end;
h[con] := v; {nút con cuối cùng trong quá trình “kéo xuống” nêu trên, là vị trí mới của v}
sh[v] := con;
end;

function lay: integer;
{lấy khỏi heap đỉnh gốc, vun lại heap để hai cây con hợp thành heap mới}
var r,c,v : integer;
begin
lay := h[1]; {lấy ra nút gốc là nút có nhãn nhỏ nhất trong các nút chưa cố định nhãn}
v := h[shmax]; {v: đỉnh cuối cùng của heap}
dec(shmax); {sau khi loại đỉnh gốc, số nút của heap giảm đi 1}
r := 1; {bắt đầu vun từ nút gốc}
while r*2 <= shmax do {quá trình vun heap}
begin
c := r*2; {số hiệu nút con trái của r}
if (c
inc(c); {so sánh nhãn của hai nút con, chọn c là con có nhãn nhỏ hơn}
if d[v]<=d[h[c]] then break; { dừng khi nhãn v không vượt quá nhãn hai nút con}
h[r] := h[c]; {chuyển nút có số hiệu là con lên nút có số hiệu là cha}
sh[h[r]] := r; {xác nhận lại số hiệu trong heap của nút mới chuyển lên}
r := c; {xác nhận cha mới để quá trình lặp lại}
end;
h[r] := v; {đỉnh v được đặt vào vị trí r cuối cùng để bảo đảm điều kiện của heap}
sh[v] := r; {xác nhận lại số hiệu của nút v trong heap}
end;

procedure dijkstra;
var i,u,j,v,min : integer;
begin
capnhat(1); {tạo nút thứ nhất cho heap}
repeat
u := lay; {u: đỉnh chưa cố định nhãn, có nhãn nhỏ nhất}
if u=t then break; {tới đích thì dừng}
dx[u] := True; {đánh dấu u được cố định nhãn}
for j:= p^[u]+1 to p^[ư1] do {j: chỉ số trong mảng ke, của các đỉnh kề với u}
begin
v := kê[j]; {v kề với u}
if (not dx[v]) and (d[v]>d[u]+c^[j]) then {điều kiện sửa nhãn v}
begin
d[v] := d[u] + c^[j]; {sửa lại nhãn của v}
tr[v] := u; {ghi nhận lại đỉnh trước của v là u}
capnhat(v); {cập nhật lại v trong heap để bảo đảm cấu trúc heap }
end;
end;
until shmax = 0; {dừng khi không còn đỉnh tự do (số nút của heap bằng 0)}
end;

procedure inkq;
var f : text; i,j : integer;
kq : k3;
begin
assign(f,fo);
rewrite(f);
if d[t]=maxc then
writeln(f,-1) {ghi kết quả: vô nghiệm}
else
begin
writeln(f,d[t]); {ghi độ dài đường đi ngắn nhất từ đỉnh s đến đỉnh t vào file output}
i := 0;
while t<>s do {lần ngược các đỉnh liên tiếp của hành trình ngắn nhất lưu vào mảng kq}
begin
inc(i);
kq[i] := t;
t := tr[t];
end;
inc(i);
kq[i] := s;
for j:=i downto 1 do write(f,kq[j],′ ′); {ghi hành trình vào file output}
end;
close(f);
end;

BEGIN
doc_inp;
khoitri;
dijkstra;
inkq;
END.

Giáo sư Edsger Wybe Dijkstra (11/5/1930-6/8/2002) là một người đi đầu trong lĩnh vực máy tính, đã mất vào ngày 6/8/2002 tại Neunen-Hà Lan, sau một một thời gian dài mắc bệnh ung thư. Bài viết này giới thiệu đôi nét về cuộc đời và sự nghiệp của ông.

Dijkstra sinh ngày 11/5/1930 tại Rotterdam-Hà Lan trong một gia đình mà bố là một nhà hoá học và mẹ là một nhà toán học. Ông đã tốt nghiệp về chuyên ngành toán và vật lý lý thuyết tại trường Đại học Leyden, sau đó lấy bằng tiến sỹ về khoa học máy tính tại trường Đại học Amsterdam. Ông làm một lập trình viên tại Mathematisch Centrum- Amsterdam từ 1952-1962; là một giáo sư toán học tại trường Đại học công nghệ Eindhoven từ 1962-1984; là nhà nghiên cứu của Burroughs Cooporation từ 1973-1984. Ông đã công tác tại trường Đại học Texas ở Austin và làm giáo sư danh dự từ 1999.
Dijkstra sống cùng với vợ, ba người con và hai cháu. Dijkstra đã nhận giải thưởng ACM Turing vào năm 1972 (giải thưởng này được coi là giải thưởng Nobel cho tin học). Ông là một thành viên của học viện hoàng gia Hà Lan về khoa học và nghệ thuật, là thành viên của một học viện của Mỹ về khoa học và nghệ thuật, và là viện sỹ của hiệp hội những nhà khoa học máy tính Anh. Ông còn nhận rất nhiều giải thưởng khác như: AFIPS Harry Goode Award, IEEE Computer Pioneer Award, ACM SIGCE Award; trường Đại học Athens đã trao tặng ông bằng tiến sỹ danh dự vào năm 2001. Tổ chức C&C Foudation của Nhật Bản đã coi Dijkstra là người có công đầu tiên trong việc xây dựng nền tảng của lĩnh vực phần mềm máy tính thông qua những công trình nghiên cứu về lý thuyết phần mềm, lý thuyết thuật toán, lập trình cấu trúc và ngành ký hiệu học.
Dijkstra nổi tiếng vì đã nhận thức được rằng logic toán học là nền tảng để xây dựng nên những chương trình máy, ngoài ra ông còn có nhiều đóng góp trong việc thúc đẩy sự phát triển của các phương pháp toán học trong khoa học máy tính. Ông là người chịu trách nhiệm xây dựng hệ điều hành theo phương pháp đồng bộ hoá các tiến trình tuần tự (sequential processes); phát triển các chương trình máy tính, các phương pháp kiểm tra chương trình chuẩn mực. Đặc biệt, ông trở nên rất nổi tiếng với thuật toán tìm đường đi ngắn nhất, với những thành công trong việc thiết kế và viết mã nguồn cho chương trình biên dịch Algol 60 đầu tiên. Ông cũng là người đi đầu trong việc đề nghị loại bỏ câu lệnh nhảy GOTO trong chương trình.
Dijkstra có khả năng viết rất đáng khâm phục. Toàn bộ các công trình của ông là một bộ sưu tập lớn với hơn 1300 tác phẩm (nếu quan tâm, bạn có thể tìm hiểu thông qua địa chỉ http://www.cs.utexas.edu/users/EWD). Ông thường xuyên trao đổi thư từ với hàng trăm người bạn và đồng nghiệp khác, tuy nhiên không phải qua thư điện tử (email) mà qua những lá thư viết tay giản dị. Ông thích dùng bút máy hơn là máy tính để viết những công trình khoa học và những lá thư của mình.
Dijkstra còn nổi danh vơi biệt tài hùng biện, sự dí dỏm và lối dùng từ thông minh. Chẳng hạn, ông có nhận xét: ″Câu hỏi máy tính có khả năng nghĩ được không thì cũng giống như câu hỏi tàu ngầm có bơi được không″; lời khuyên của ông cho một nhà nghiên cứu khi được hỏi làm thế nào để chọn lựa được chủ đề nghiên cứu là: ″Hãy chỉ nên làm những gì mà bạn có thể làm″; nhận xét của ông trong buổi nói chuyện về giải thưởng Turing của mình: ″Với tư cách là một công cụ, thì máy tính chỉ là một làn sóng nhỏ trên bề mặt nền văn minh của chúng ta. Với tư cách là thách thức trí tuệ, máy tính là tiền tiền lệ trong lịch sử văn hoá của loài người″.
Dijkstra làm giàu thêm cho ngôn ngữ máy tính với nhiều khái niệm và thành ngữ như lập trình có cấu trúc,sự đồng bộ hoá, semaphores, câu lệnh.. Cuốn từ điển Oxford English Dictionary trích dẫn các từ như ″vector″ và ″stack″ mà ông đã đề xướng.
Dijkstra thích chơi nhạc của Mozart bằng đàn piano cho bạn bè thưởng thức. Ông và người vợ của mình có thú vui đi thám hiểm những công viên quốc gia bằng xe buýt riêng, chiếc xe được gán cho cái tên Touring Machine, trong đó ông đã viết rất nhiều công trình khoa học.
Trong sự nghiệp khoa học của mình, Dijkstra đã nghiên cứu và theo đuổi những tư tưởng có tính học thuật cao, không bị ràng buộc bởi chính trị, thương mại, hay sự thúc ép bên ngoài nào. Nói một cách đơn giản, vẻ đẹp và sự tao nhã trong lập trình và toán học đã là nguồn cảm hứng vô tận của ông. Ông giải quyết công việc một sự tập trung cao độ, ông còn luôn luôn đưa ra nhiều thách thức cho đồng nghiệp để cùng nghiên cứu. Trong thời gian rảnh rỗi, ông luôn sẵn lòng làm vai trò như một nhà chính trị trong việc thúc đẩy sự phát triển của xã hội, ông thường chỉ ra những sai lầm trong lối suy nghĩ của mọi người, chỉ ra sự nguy hiểm của những tư tưởng cơ hội.. Ông có khả năng tổ chức mọi người thành những nhóm thảo luận, nghiên cứu nhỏ nhằm góp phần nảy sinh ra những ý tưởng mới mẻ.
Dijkstra còn được mọi người kính trọng và khâm phục bởi ông là một con người thông thái và rất mực công bằng.

Nguyễn Văn Trường
Trường ĐHSP Thái nguyên

Most of the languages in use today, do indeed have the gotostatement. As we do already know, the goto statement is used to unconditionally jump from place to place within a program, with destinations marked as labels. As you can already guess, this can make a program really hard to read, with its particularlyjumpy nature. The programmer, with all his wits, could well have written a perfectly unambiguous program, but what about his code? Sure ; he knows all about his own program, and is in a position to debug it and make changes, but what about debugging, when it comes to a team environment? While our smart programmer is on leave in Hawaii, rewarded for his hard work, how miserable life will be for his coworkers!
Oh, and did I mention the program had 352 goto statements?

In the days of the structured programmer, the goto statement was a very powerful tool in the hands of a very powerful programmer. His days, however, are no more. Neither him nor his tool are powerful anymore. However, it would be wrong to say that the goto statement does not have any application in high level programming. While some high level languages, like Java do not support the statement, other languages such as C#.NET continue to allow it ; and it proves to be useful in causing fall-throughs in switch-case blocks.

The popular saying among many, so-called high level programmers is, “Never use GOTO statements” ; but this need not be completely true. However, there have been several great computer scientists, whose work has formed the base for what most of computer science is today, have sternly voiced their concerns against the goto statement. The most popular of such cases is Edsger W. Dijkstra’s letter to Communications of the Assosciation for Computing Machinery in 1968, titled A case against the go to statement. (here)

Since a number of years I am familiar with the observation that the quality of programmers is a decreasing function of the density of go to statements in the programs they produce. Later I discovered why the use of the go to statement has such disastrous effects and did I become convinced that the go to statement should be abolished from all “higher level” programming languages (i.e. everything except –perhaps- plain machine code).

In reality, goto statements belong to assembly language code, where the program, has no other option, but to jump (conditionally or unconditionally) to memory locations, specified explicitly in the program itself. When structural programming was programmer fashion, the goto statement, as I already mentioned was a very powerful tool; but this was before thewhile and for loop even came into existence. Now, with better options at hand which were not available at earlier times, we must strive to do whatever we can to make our programs easier to manage, read and debug - we must strive to make our programs more high-level.

The go to statement as it stands is just too primitive, it is too much an invitation to make a mess of one’s program.

The use of the word mess, in my opinion is quite apt. Imagine a program with 352 goto statements. You’re probably going to spend more than half of your office hours scrolling up and down, trying to locate the labels, and make sense of what the program actually does. (And I’d sincerely hope you’re not using the vi text editor.) Owing to this seemingly random flow of controlbetween various statements, programs that use too many gotostatements earn the “Spaghetti Code” nickname, which falls very short of a complement.

So why would you use a goto statement anyway? It is also a proven fact that every goto statement can be replaced with a suitable implementation of a set of looping constructs. (except for the fall through case in switch blocks I mentioned earlier). The reason for this is probably, that most programmers think (or like to think) in the way a computer thinks; executing a set of statements, and jumping to a new set of statements when a branching instruction is encountered. In a way, this is what dividing your programs into methods/functions also achieves, but it is much easier to manage code.

So, to conclude, to not go to is a much more sensible decision.

La crisis del software, en mi opinión, es algo que todavía no se ha superado, desde que se empezase a hablar de ella, en la década de los sesenta, a partir del genial holandés Edsger Dijkstra en su obra “The Humble Programmer”

Bien es cierto, que hay autores, con un prestigio infinitamente multiplicado por infinito superior al mío, que consideran que es algo que está superado, como por ejemplo, Roger S. Pressman, que lo redefine como aflicción crónica, al existir cada vez más casos de éxito.

Mi experiencia, al menos en el segmento en el que me muevo, es que se quiera llamar como se quiera, la crisis del software sigue presente.

La crisis del software se refiere principalmente a las siguientes características del proceso de desarrollo:

- Incumplimiento sistemático de los plazos de entrega.
- Desajuste entre el presupuesto inicial estimado y el presupuesto final del proyecto.
- Baja calidad del producto final: Incumplimiento de especificaciones y dificultad de mantenimiento.

Que alguien me diga en qué porcentaje de los proyectos en los que ha participado como programador, analista, jefe de proyectos o gerente se ha cumplido algunas de las premisas anteriores. En bastantes, ¿verdad?.

Por eso pienso que la crisis del software continua, por mucho que la aparición del concepto de ingeniería del software o de múltiples metodologías hayan intentado paliarla.

Bien es cierto, que las bases para eliminar la crisis del software en un proyecto de desarrollo de software son muy conocidas por todos, lo que pasa es que son tantos los ingredientes a utilizar (unos dependientes del grupo de desarrollo y otros no) para que un proyecto salga bien en plazos, presupuesto y calidad, que no resulta nada sencillo (aunque no es imposible) conseguirlo.

Por todo lo anterior, pese a que la solución tiene una base metodológica y de disciplina (de todas las partes que intervienen en el proyecto, teniendo mucho peso la parte usuaria), la base para arreglarla es cultural, es decir, la adquisición de buenos hábitos de base para el desarrollo de proyectos software (ya que sin esta cultura, la metodología se llenará de polvo en las estanterías y la disciplina un bien perecedero) y la erradicación de los mitos del software en todas sus vertientes.

Nadie tiene la llave para ser infalible en los proyectos de desarrollo de software, es decir, como he dicho antes, un proceso de desarrollo tiene muchos condicionantes y es muy complicado manejarlos todos, sobre todo cuando no dependen de uno. En cualquier caso, lo que hay que intentar siempre es tender a hacer las cosas de la mejor manera posible y a intentar cumplir los objetivos de plazos, presupuestarios y de calidad, porque si hay una cosa que debe clara a todos, es que si un proyecto no se enfoca hacia esos objetivos, es complicado, muy complicado, que se consigan por casualidad.

Jeff Atwood has long blogged about “coding horrors”, but reading this post crystallizes for me why I’ve left the programming field.

This is because like most folklore about programming, the sage advice ignores the essentials.

Regular expressions were originally purely mathematical expressions which could be ambiguous (such as “*A”, anything followed by A, where “anything” might include A). They could be ambiguous because their function was to declare a class of languages.

“*A” (“anything A”) doesn’t preclude A from appearing more than once in a string in the language it defines because it is silent about what follows the last A. Unlike the corresponding regular expression code in a “real” regular expression used by a programmer, “*A” is silent about what follows A.

For the mathematician, “anything A” is implicitly followed by indeterminancy. He will interpret “anything A” as possibly including the letter A in anything since it’s not followed by “end of signal” or “nothing”.

Mathematically, “anything A” is perfectly fine, or, if you prefer, well-formed mathematical expressions are beyond good and evil and must be taken on their own terms. For example, the “limit” of calculus, were it a programming tool or concept, would be unacceptably vague. Science deals with partial knowledge, but in programming we try to control everything.

Which means the programmer has to translate the math to “*A$” where the dollar sign is some character meaning “end”.

But “end of input” never occured, as far as I know, the John von Neumann or Claude Shannon, two of the original mathematicians to work with mathematical regular expressions. This is because end of input has no special mathematical meaning.

Consider this. The programmer defines $ (end of input) to mean “what happens at the end of an input string”, and he is thinking about phenomena without mathematical significance, such as some user pressing the Enter key.

But the mathematician is not at liberty to delimit his input (and it is a programmer failing to see how the latter’s ability to set norms and conventions for his work makes him a technician, not a scientist). If the mathematician is told, $ means end of input, he will ask, what come after that? To him, $ is just another symbol, without the power to forbid other symbols to follow it.

John Cusack, in the 1989 film Say Anything, is asked by his girlfriend’s father’s criminal tax accountant what he wants to do with his life. Cusack says, I dunno, I just want to hang out with Mister So and So’s daughter. When pressed, Cusack says, well I don’t want to “process” anything.

Likewise, the mathematician, unlike the programmer, is uninterested in “processing data”, so to a mathematician, $ have no meaning…just as Cusack seems to the criminal tax accountant to be uninterested in Holy Money.

“Anything A” is mathematically meaningful but lousy “code”. This is because it cannot be a subexpression in a larger regex without trouble.

Consider “*AB”. As code it doesn’t specify whether AB can appear as part of “anything”. Worse, different regular expression systems in common use will treat this situation differently, and are documented in ways that imply that there is more than one way of interpreting “*”. Here, the programmer is just kidding in using asterisk: he means “anything except, of course, AB, silly”, and worse, some regexp systems pander to this sloppy thinking.

The problem is that sequencing (one basic RE subexpression such as “*” followed by another such as “AB”) is not thought of consciously as a regular expression operator of equal status with alternation (*|AB). But concatenation, sequencing is a genuine operator, with three possible interpretations:

1. If the handles of the sequenced pair share a non-null common set of characters, refuse to proceed.
2. If the handles share this non-null intersection, prefer the left hand side
3. If the handles share this prefer the rhs.

Programmers are if Prometheus clumsy, for they pervert mathematics.

Which brings me to Jeff’s article. The credit crisis alone, which has a large software component, indicates that there’s something very wrong with programming as folklore.

Programming-as-folklore consists of pseudosage advice meant to avoid difficulty. Now, there’s nothing wrong with artisanship and craft, but programming folklore replaces mathematics.

In mathematics, “anything A” means “anything followed by the letter A, including AA or AAA”. In programming it might or might not be a bug, because no independent effort has been made to “standardize” regular expressions.

But “standardization” brings me to the real horror…the Heart of Darkness, if you will, or, if you prefer, Apocalypse Now.

“Standardization” is a bureaucratic ersatz for something hero computer scientist Edsger Dijkstra said he wanted in his 1972 Turing Award lecture and didn’t get. Dijkstra had been horrified, like Mistah Kurtz, by the IBM 360.

He was horrified by the IBM 360 because after several years of work which had shown the importance of being able to save the overall state of a computation quickly, safely, and in the general case, the designers (led by Gene Amdahl) decided that there needed instead to be 16 [sic] “general-purpose registers” named R0..R15…and no stack in sight. As a direct result, in the 1970s, I knew several bitter, twisted, and prematurely aged assembler programmers who each had come to terms, each in his own way, with what you do when you call a subroutine.

Amdahl’s anti-intellectualism treated the actual normal case, one of almost overwhelming complexity in real workplaces, as something that would almost never obtain: his reasoning resembled that of Columbia space shuttle engineers who reasoned that because by 2003 large chunks of foam had not dropped off Columbia, things would continue as before. But in reality, there were all sorts of complex applications for the 360 even in the “ordinary” business world.

For example, graphs, lattices, trees and recursion are thought to be “highly theoretical” by “ordinary business programmers”: but I encountered recursion implemented foolishly and by accident in software at a re-insurer (an insurance company that insured other companies against loss). The difficulty of “unwinding” securitized mortgages in today’s credit crisis is caused by the fact that in the large, a securitized instrument is a vast tree of financial relationships, encoded in software. In some cases, this branching tree may be a graph, for nothing in many systems prevents a derivative from being linked to itself through an indirect chain.

Dijkstra felt that some sort of tribunal of academic people should vet new computers for their mathematical safety and correctness. Suffice it to say, he was ignored, with the ersatz being “standardization” being driven by manufacturer greed, as in the absurd case of the “standardization” of C.

But this is a special case of something so general as to constitute our world: for the fact is that people, in an administered world, are so administered, and so fucked-over, from cradle to grave as to not be able to think outside the real box. In the 1950s, in Britain especially, in the USA to a degree, this was the welfare state, but the welfare state was of course entirely too much the carrot and not the stick, so the carrot is also the stick.

As such, when Dijsktra mentions a tribunal of academics, we get a standardization committee. Such committees, however, are unimpressed with anything like mathematical elegance.

“Regular expressions” retain for this reason a meaning only in mathematics. In programming, they are whatever Perl, or regex, chooses them to be.

I bailed happily out of the cynical world this created in programming.

Vamsi asked me such a delicate question that instead of answering him as a comment, I thought of coming up with a new post. His question was:

But how does one know if he/she is in “true” love??

Being a novice in the field, I consulted bhOndOO, the person having long time experience in Love. He told me the following symptoms. Although the symptoms are related to iisc life, those can be easily transformed into the appropriate environment. Further, the symptoms assume a male Lover, appropriate modifications should be done for a female Lover. Here is what bhOndOO says.

You are in Love:

• when the first thought in the morning (or whenever you wake up) is not that of your advisor, but of her.
• when for no apparent reason, you smile to yourself and look around to see nobody witnessing it.
• when you walk on the road in front of the library and start noticing pairs of birds rather than worrying about the shitty blessings.
• when you are sitting alone in your hostel room, although impossible, you feel that she would knock at the door.
• when you avoid calling your friends on mobile because you are expecting a call from her and she should not receive an engaged tone.
• when she calls and you see her name on the mobile display, smile follows the missing pulse. When you say “Hello”, you try to hide all your excitement as if her number is not even stored in your mobile.
• when you keep looking at the tea board entrance or the mess entrance for her arrival — even if that never happens.
• when you pay for her in tea board, you start thinking about running the house together!
• when you see a happy couple with a child in Nesara, you steal a glance at her for her reaction.
• when you miss a lecture to have a coffee with her.
• when the first thing you notice when you reach the department is her bicycle.
• when on her birthday, you gift her something that she casually talked about almost 11 months back.
• when you keep searching for her name on google, keep checking her orkut scrapbook, keep checking her friends’ scrapbook for what she has written, and feel skeptical about the boy who writes often in her scrapbook.
• when you try to postpone the meeting with your advisor because you have to meet her.
• when asleep, you dream of her getting married to Gullu.
• when you read The Fountainhead, you imagine yourself to be Howard Roark and her to be Dominique Francon.
• when you are appreciated by friends or advisor, you wish hard that she should have been there.
• when you share your childhood photo with her.
• when suddenly Dijkstra’s shortest path algorithm starts outputting the path from your hostel to the department via her hostel.
• when you feel happy to see her smiling.

What are your symptoms?

Came across this article while perusing the CodingHorror blog today. Quite interesting read, too. You should read this one if you’re in the same line of work as I am

http://www.codinghorror.com/blog/archives/001249.html

You must not give the world what it asks for, but what it needs.

-Edsger Wybe Dijkstra.

Dijkstra aims to present programming “as a discipline on its own merits, as a methodology of constructive reasoning applicable to any problem capable of algorithmic solution,” quoted from Niklaus Wirth. To this end, Dijkstra describes “the programmer’s activity as ‘designing a class of computations’, rather than as ‘making a program’.”

What is so striking about these descriptions is their attention toward the abstract. Programmers are not just looking for a computation, but a class of them. A class is used to describe some collection of items—in this case, computations—that have some major feature in common. By focusing on this common feature, we make our attention more abstract and less stuck on the particulars.

For example, sorting words into a dictionary and sorting PIN numbers numerically involve two different concretes. The first deals with letters, the second with numbers. But look at what they have in common: both the letters and the digits are grouped into a larger whole, say a “word” in the general sense (including letter words and number words), and both the alphabet and the numbers have an order to them. When we realize that there is an order to these basic building blocks (letters or numbers), we no longer care whether they are numbers or letters, and instead, we just apply a sorting algorithm. All that was needed to sort is an ordering system.

Dijkstra’s work, especially in the middle chapters with the study of sequences, has led me to a deeper understanding of where the mathematics comes into computing. By Dijkstra’s definition, computing must be a process of abstraction. You must be able to identify when the computations are the same, when they’re different, and when certain ones are specific instances of another more general one. This is how one can form those classes of computations.

Because there is a serious attempt to focus on the abstraction, it makes sense that mathematics enters computing. Mathematics is a well-refined language for identifying exactly what those common features between objects are and what logical consequences those features lead to. Math itself describes abstractions.

The Hoare logic was especially exciting. Although it is clearly mathematical, it’s exciting to watch the concept develop out of the need to communicate and refine algorithms. This truly is “applied math” as Dijkstra had said. With the mathematics of the Hoare logic, one is able to identify quickly what are the important parts of the programs are, without getting bogged down by the details.

And thus, with the mathematics, one is able to quickly identify where the classes of computations are, because it is easy to see which computations have the same form or not. Once one has those classes of computations, arriving at a suitable algorithm for a particular job just means following a similar abstraction one took to identify those classes in the first place. If that falls into a class that has already been solved, then you benefit from the work done before you.

Dijkstra is a Dutch Photography/ artist who works mostly on single person portraits, but generally forming some sort of larger series. She has approached topics such as social grouping and the passage of time.

In the series below Dijkstra photographs young men and women who have recently been enlisted into military service, Shany (below) is photographed in 2002 at the induction center in Israel and this continues over 18 months. Each portrait is an intimate reflection on identity and personal expression in the face of military oppression.

WEBSITE

L’informatica non riguarda i computer più di quanto l’astronomia riguardi i telescopi.
(Edsger Wybe Dijkstra)

Note dall’Angolo di Dani:

Dijkstra, per chi non lo conoscesse, è tra i personaggi più odiati tra coloro che studiano informatica, per due fondamentali ragioni:

1. Nessuno conosce l’esatta pronuncia del suo cognome (provando ad associare il nome esce poi una specie ci scioglilingua)
2. E’ a lui che è attribuito uno degli algoritmi alla base della ricerca operativa, quello relativo ai cammino minimi, richiamato in problemi di reti e programmi software.

Nonostante ciò, tutti riconoscono la sua genialità: basti pensare che è tra coloro che han ricevuto un Premio Turing, una specie di equivalente del Premio Nobel (inesistente per l’informatica).

Note: This post is a first attempt to write about topics that are of professional or didactic interest, but which may not be profound enough to merit a separate journal paper or other publication. Some of these topics originated from research-related conversations around campus, and others from internal group seminars in the past few years. I request feedback about length, tone, and format styles.

A. Introduction

There are generally two separate decisions to make in any computational problem. The first is to represent the knowledge about the problem in some useful way. Usually we are required to choose one of several possible representations. The second is to choose a method (or an algorithm) that can operate on the representation to produce the required result. Depending on the representation chosen, there may be several algorithms available to choose from.

From a practical perspective, a good algorithm is often one that is acceptably fast and makes acceptably low demands on system resources (like memory), and the analysis of algorithms is a rich field in its own right with powerful mathematical tools. Choosing the right representation, however, is more often the result of personal or learned experience based on a rare insight than on rigorous analysis. This post shows the importance of knowing what representation to use for what situation.

B. Example

Here’s an example problem (Problem 172 from Project Euler) that shows the importance of the right representation:

How many 18-digit numbers n (without leading zeros) are there such that no digit occurs more than three times in n?

(I recommend that you spend some time analyzing the problem by yourself before reading further).

C. First Representation

Now, what is the first representation that springs to mind? Most of us probably visualized a one-dimensional array, each element representing a digit of the 18-digit number and ranging in value from 0 to 9 (except for the element corresponding to the first digit, which goes from 1 to 9). Let’s call this representation R1.

Clearly this is a natural first choice for a representation, and a natural choice of accompanying algorithm (algorithm A1) would be a bunch of nested for-loops, one for each digit, with a series of if-else statements buried inside all the loops to check for legality (no digit should occur more than thrice), and a statement to increment a counter for every legal number found. The total time spent inside the loops is then evaluations, which would take a few hundred thousand years to complete.

One “refinement” to this brute-force approach would be to use backtracking, which is to bring some of the if-else checks from the deepest for-loop to some of the outer for-loops, so that illegal sub-numbers with just a few digits are trapped and pruned off early instead of letting them grow into full-fledged 18-digit numbers. Let us be extremely generous and say that backtracking would speed up the brute-force algorithm A1 by a million times. The estimated run time is now “only” loop evaluations, and can be done in a few months.

Backtracking has its advantages over brute-force, but thinking up any improvement to the algorithm A1 without changing the underlying representation R1 is essentially an exercise in futility, because at the very least, no algorithm based on A1 can go faster than having to evaluate the number of legal solutions, which could still be intractably large. A better representation is needed.

D. Second Representation

Here are some thoughts:

1. The problem is to find only the number of possible solutions, not to actually list them out. (Knuth^[1] calls these two distinct questions “enumeration” and “generation” respectively, which is the terminology I adopt). We need an algorithm that can compute the final number of solutions without having to wade through each individual solution in turn. It’s like the difference between saying “There are permutations of a deck of cards”, which takes 3 seconds to say out loud (unless you’ve been taking interesting medication), and having to list out all permutations and counting them one by one, which would take times the age of the universe. We need a representation that will allow such an algorithm to operate.

2. The number of legal 18-digit numbers (those with at most 3 occurrences of any digit) is less than the number of all 18-digit numbers. We would prefer a representation that allows for only the legal numbers to be represented if possible.

3. If an 18-digit number is legal, then all permutations of its digits are also legal. Additionally, if it is illegal, then all permutations of its digits are also illegal. To restate, what is important for the problem is only the number of instances of each numeral (0–9), and not their position within the 18-digit number itself.

The third point above immediately suggests an alternate representation R2. This representation is a one-dimensional array of length 10, representing the numerals from 0 to 9. The value of each element of the array is the number of occurrences of the corresponding numeral, which we can limit to be in the range [0,3] since we know that no numeral can occur more than 3 times.

Further, the sum of all the array elements should be exactly equal to the number of digits (18 in this case) of the final number. Even the most basic brute-force algorithm A2 will now have to examine only = a million cases for validity. It is also easy to speed up algorithm A2 using the equality constraint that the array elements have to add up to 18, by looping through only 9 of the elements and computing the tenth as being 18 minus the sum of the first 9. The number of distinct cases is now only = a quarter million. For each array, the number of distinct permutations of the 18-digit number is given by the multinomial of the array elements: . All we need to do is run through the cases, check for validity of the tenth digit, and if so, add the multinomial to the answer. (There’s some minor bookkeeping to keep track of the starting digit not being 0, but it’s easy to figure out). This approach takes about a second to run, depending on what else you have running in the background. As before, it can be sped up by backtracking, using the fact that if a partial sum of the array elements has exceeded 18, then no assignment of values to the remaining elements will reduce it to within 18, and can therefore be pruned off early.

E. Third Representation

It might look like that is the end of the story, but if we revisit the third point from above, we see that it is only the number of instances of each numeral (0–9) which is required, and not their identities themselves! Representation R1 differentiated between two different numerals and also their position within the 18-digit number. Representation R2 does not bother with the position, but still differentiates between the numerals themselves. Now, we may observe that the number of 18-digit numbers made up of 3 instances each of the numerals {1,2,3,4,5,6} is exactly equal to the number of 18-digit numbers made up of 3 instances each of the numerals {4,5,6,7,8,9}. These were represented two different times in R2, when all we really needed was a way to represent (just once) the fact that 6 numerals were represented 3 times each and the remaining 4 were not represented at all.

Representation R3 implements exactly that, with a one-dimensional array of length 4, representing the number of numerals with 0, 1, 2, and 3 instances each.

Clearly, the sum of the array should always be 10 (being the number of numerals in 0 to 9), and their index-weighted sum should always be 18 (being the number of digits in the final number). Since each element is required to be a non-negative integer, even a brute force approach A3 has only possibilities for the ith element of the array. The two equality constraints chop off another two degrees of freedom, and even the crudest brute force only lists 7 possibilities for (from 0 to 6) and 10 possibilities for (from 0 to 9), with and being computed and checked for legality from and . Out of these 70 possibilities (which can be reduced drastically by adding backtrack to A3), it turns out that there are only 17 legal combinations.

(Recall we started with combinations in the first representation). Computing the combinatorics for each of the 17 legal combinations is now a product of two multinomials, one representing the number of ways that ten distinguishable numerals can be partitioned into four sets of sizes through , and the second representing the number of distinct ways that the 18-digit concatenation of those numerals can be permuted. The bookkeeping to prevent the first digit being 0 is a little more involved, and I leave it as an exercise to the reader.

F. Final Thoughts

Here are some final thoughts:

1. Representation R1 is unequivocally the wrong representation for this problem. For most problems both R2 and R3 are suitable, but the choice between them depends on the problem instance. For example, if the constraint is to enumerate the number of n-digit numbers no digit of which occurs more than m times, R2 (and A2) will scale polynomially in m with a constant exponent of 10 (the number of numerals), while R3 (and A3) could scale exponentially in m in the worst case. However, it is reasonable to suppose that the average case runtime for R3 and A3 is probably much better than for R2 and A2, as long as the instances are not pathological.
2. Algorithm A3 is more complicated than A2, requiring some more bookkeeping. For problems with many edge cases or corner cases, the relative simplicity (and consequently the improved maintainability) of R2 and A2 may be worth the lower execution speed.
3. The specific problem chosen in this may be easy, but it captures the issue of choosing good representations for other (more serious) problems. Still, as of date, only 454 people have solved the problem on Project Euler, compared to over 48,000 who have solved the problem of summing all numbers below 1000 that are multiples of 3 or 5, indicating that for every 100 people who know how to use a for-loop correctly, only one knows how to choose a good representation.
4. To quote Art Westerberg^[2]: “Our ability to enumerate requires we have a way to represent the space of alternatives. Such a representation may be the one real contribution of a Ph.D. thesis — i.e., they are not that easy to discover.”

References:

[1]. Donald E. Knuth, The Art of Computer Programming, Volume 4 Fascicle 0, Introduction to Combinatorial Algorithms and Boolean Functions (2008), ISBN 0-321-53496-4, page 1.

[2]. Arthur W. Westerberg, A retrospective on design and process synthesis. Computers and Chemical Engineering
Volume 28, Issue 4, 15 April 2004, pages 447-458.

Further reading:

1. Edsger Dijkstra’s EWD1250 and EWD1255 are particularly relevant in the context of this post.

2. Donald Knuth’s TAOCP, as always. If you have never read TAOCP before, get thee to a library, go: farewell. Or, if thou wilt needs hyperlinking, hyperlink this. To a library, go, and quickly too. Farewell.

import java.util.*;

public class DijkstraASP{
public static void main(String args[]){
Main m =new Main();
}
}
class Verteks{
int no;
int value;
String color;
Verteks(int no , int value){
this.no = no;
this.value = value;
}
Verteks(int no,String color){
this.no = no;
this.color = color;
}
public String getColor(){
return color;
}
public void setColor(String color){
this.color = color;
}
public int getValue(){
return value;
}
public int getNo(){
return no;
}
public void setValue(int a){
value = a;
}
}
class Main{
public Main(){
Scanner in = new Scanner(System.in);
int n = 3;//jumlah verteks
PriorityQueue<Verteks> pq = new PriorityQueue<Verteks>(n,new Comparator<Verteks>(){
public int compare(Verteks a,Verteks b){
if(a.getValue() < b.getValue())
return -1;
else
return 1;
}
});
Verteks d[][] = new Verteks[n][n];
int edge[][] = new int[n][n];
for(int i=0 ; i<n ; i++){
Arrays.fill(edge[i] , 0);
for(int j=0 ; j<n ; j++){
d[i][j]=new Verteks(j,Integer.MAX_VALUE);
}
}
for(int i=0 ; i<n ; i++){
d[i][i].setValue(0);
}
edge[0][1] =edge[1][0]=2;
edge[1][2]=edge[2][1]=1;
edge[0][2]= edge[2][0]=4;
int u=0;
for(int i=0 ; i<n ; i++){
pq.add(d[i][i]);
while(!pq.isEmpty()){
u = pq.poll().getNo();
System.out.println(“u :”+u);
for(int j=0 ; j<n ; j++){
if(edge[i][j]!=0){
if((d[i][j].getValue()) > (d[i][u].getValue() + edge[u][j])){
d[i][j].setValue(d[i][u].getValue()+edge[u][j]);
pq.add(d[i][j]);
}

}
}
}
}
for(int i=0 ; i<n ; i++){
for(int j=0 ; j<n ; j++){
System.out.println(d[i][j].getValue());
}
}
}
}

Computer Science is no more about computers than astronomy is about telescopes.

-Edsger Wybe Dijkstra.

I had planned to work more on the game during the Christmas holidays, but I did not start until a few days ago. But I made some clear progress these last few days.

The algorithm that calculates the set of hexagons a unit can reach now takes terrain into account. For instance, crossing a forested hexagon costs more movement points than passing through a hexagon representing farm land.

The screenshot shows the hexagons the blueish tank near the bottom-left corner can move to. The forest hexes at the top were previously reachable.

At first, I thought all I had to do was associate costs with every edge and sum them up as I traversed the graph, but after a while I realized that breadth-first search (which is what I used before) cannot be used  with weighted graphs to solve this problem (unless all edges have the same weight). So I had to throw away the old search code and implement Dijkstra’s algorithm instead. Took me longer than I expected, but now the code is cleaner and handles weighted graphs properly.

I also simplified the rules for how close to an enemy a unit is allowed to move without having to stop. The new rule is simply that you cannot pass through a hex that is adjacent to an enemy unit. That is all that is needed, really. Thanks Peter E. for making a comment that made me realize how pointless the (relative) complexity of the old method was!

here is one of the assignments i liked to be doing in Scientific Computing

specifically a Mathematical Programming assignment

i could have just implemented a Console application running the algorithm and get my marks, but thats not what i need from SC Dept

i think it would be useful for those who want to learn one of the algorithms it runs or for those who want to see what a SC assignment looks like

well here is the main form 

as you can see the form is divided into two parts the settings part and the drawing panel

in the settings part you’ll find all the data about your Graph the Nodes, their positions and algorithm specific information as the start and end nodes of the algorithm – if it needs -

to draw a graph you should first add the nodes of the graph, by just writing the name of the node and press “Add Node”

 You can enter as long name as you like but i doubt that all the name will appear on the drawn graph, (you’ll see what i mean now)

and after you add it it will be drawn in the drawing area

as in the next figure i’ve added some nodes

note that when i added the nodes their names appeared in the upper-leftmost  list A,B,C,D and End

and on the drawing panel only one node is shown

that’s because all the nodes are drawn in that location

you can move the node by whatever drag-drop , select it and double click anywhere on the drawing panel and it will appear there

or you can select it and edit it’s X.Pos & Y.Pos here

 but make sure when a node is selected it’s name is written in this textbox and it is highlighted   in the list 

after you move the Nodes to another positions now you should set the edges between the nodes

in the algorithm specific part you’ll find a hyperlink “Manage Weights”

click it and another form containing the adjacency matrix will show up

a “0″ means no connection

here you can enter the weights of the edges between the  nodes

in some algorithms which operate on nondirected graphs where the direction won’t matter u’ll find this form makes itself symmetric whenever you enter a value

as when you enter the value from “A” to “B” you’ll find the same value Automatically written from “B” to “A”

then…

after you enter the whights just close the form and the graph will be drawn

like this 

note that the number written above each node is it’s weight , cost or whatever, according to the algorithm.

and the red number on the edges is it’s weight ( the numbers you entered in the adjacency matrix form -don’t they look familiar :D – )

and this is how it looks like for the algorithms that use Directed edges

then what you should do now is keep clicking the ‘Next Step” button till the algorithm finishes

but first some algorithms need to have the start and end Nodes specified like Dijkstra and Max Flow

this is the Shortest path between “A” and “C” after some “Next Step” clicks

“The black Edges are the path”

and the number written above the “C” Node – which is not visible – is the total cost to get there form “A” i guess it’ll be 31.8 or you can move the node and see it

you can get the program from my box and watch the other algorithms

you can move between algorithms by clicking those arrows

you’ll find Dijkstra , Kruskal MST , Prim MST and Ford Fulkerson Max Flow algorithms implemented

you can also save the graph to a file and load it again anytime

and about that slider on the top left of the drawing panel :|

why would anybody place a slider on a drawing panel ?!!!!!

of course it is a zoom control !! :| , :|  -sort of… -

i think i’ll write how to implement your algorithm in this project soon isA

ah ..

I Forgot…… 

it uses framework 3.5 to run

Happy Eid ,