qnikst/qnikst.github.com

2013-09-09.1

1 parent 42ede3f commit 6af807bca78082ef7aa8fe9e1ba872e0cd83a575 committed Sep 9, 2013
Showing with 35 additions and 26 deletions.
1. +8 −6 posts/2013-09-08-pathfinding.html
2. +9 −6 posts/2013-09-08-pathfinding.lhs
14 posts/2013-09-08-pathfinding.html
 @@ -71,7 +71,7 @@ -

Basic algorithm

+

## Basic algorithm

The basic idea of our solution is: ‘we need to create a list of the locations that is reachable from initial location sorted by distance’. You can this about this solution like we move in all possible directions at the same time. Then we can filter out final destination and find history related to the correct solution.

Terms: frontier - a list of possible locations with distance from the starting point, sorted by ascending distance.

> type Frontier0 = [(Loc, Dist)]
@@ -106,9 +106,9 @@

Basic algorithm

<> is a function that will merge and sort 2 lists. You can see result of the merge shown with dashed lines.
-

+

Now we can review types that we will use.

-

Candidate

+

### Candidate

All elements in a resulting set and a frontier are possible canditas for a solution, so they need to contain all temporary information (Distance) and information that we will need when we’ll filter out this solution (History). So we need to introduce a newtype for a candate, we use newtype here because we will need to redefine some properties otherwise we could use a tuple (,,):

> newtype Candidate = Candidate (Loc,Dist,History) deriving Eq   -- possible solution

And helper functions:

@@ -117,7 +117,7 @@

Candidate

> > candidateHist :: Candidate -> History > candidateHist (Candidate (_,_,x)) = x -

Ascending list

+

### Ascending list

As we have seen in the algorithm resulting list and frontier are ascending lists. So we may introduce special type that will preserve this property. This will help us to avoid additional mistakes, and can help with undestanding of our solution. This type is isomorphic to the List, however we can’t just use a newtype as we shouldn’t unpack pure list from the AscList:

> data AscList a = (:<) a (AscList a) | Nil

It’s easy to see that AscList forms a monoid with regard to concat operation, so we can use this information:

@@ -140,11 +140,11 @@

Ascending list

> instance Ord Candidate where
>     compare (Candidate (_,d1,_)) (Candidate (_,d2,_)) = compare d1 d2

Now we can guarantee that lists are properly ordered.

-

Builder seed.

+

### Builder seed.

In order to create list we will use unfoldr :: (b -> Maybe (a, b)) -> b -> [a] combinator. On each step we will create one new element and return new seed. So we will need to store frontier in the seed. Additionaly we will use one optimization: we will store a list of visited locations (that exists in result array) and we will filter out locations that we have visited, so we need to store a set of location. So resulting type will look like:

> type Visited = Set Loc                  -- visited locations
> type Seed = (AscList Candidate,Visited) -- seed of the algorithm
-

Solver

+

## Solver

Now we are ready to introduce our solver:

> solve :: LMap       -- ^ map
>       -> Loc        -- ^ finish location
@@ -177,6 +177,8 @@

Solver

> , (ls' <> xs, Set.insert x visited))

Yachoo! we have a solver. However it will work badly on the big maps and we need to use more advanced methods, like A*. But we need to fix Candidate ordering function.

I’ve heard that it is possible to use comonad approach to solve this problem however I couldn’t find any example of this approach.

+
> test = solve testMap 5 1
+

as a result we will have [5,4,3,2,1]. That is correct solution.

15 posts/2013-09-08-pathfinding.lhs
 @@ -40,7 +40,7 @@ Most of them are just type synonyms:
-## Basic algorithm +\## Basic algorithm The basic idea of our solution is: 'we need to create a list of the locations that is reachable from initial location sorted by distance'. @@ -95,11 +95,11 @@ We added current distance (5) to distances to the current locations and add them `<>` is a function that will merge and sort 2 lists. You can see result of the merge shown with dashed lines.
-## Additional types. +\## Additional types. Now we can review types that we will use. -### Candidate +\### Candidate All elements in a resulting set and a frontier are possible canditas for a solution, so they need to contain all temporary information (Distance) and information that @@ -117,7 +117,7 @@ And helper functions: > candidateHist :: Candidate -> History > candidateHist (Candidate (_,_,x)) = x -### Ascending list +\### Ascending list As we have seen in the algorithm resulting list and frontier are ascending lists. So we may introduce special type that will preserve this property. This will help @@ -156,7 +156,7 @@ Candidates: Now we can guarantee that lists are properly ordered. -### Builder seed. +\### Builder seed. In order to create list we will use `unfoldr :: (b -> Maybe (a, b)) -> b -> [a]` combinator. On each step we will create one new element and return new seed. So @@ -168,7 +168,7 @@ So resulting type will look like: > type Visited = Set Loc -- visited locations > type Seed = (AscList Candidate,Visited) -- seed of the algorithm -## Solver +\## Solver Now we are ready to introduce our solver: @@ -212,3 +212,6 @@ more advanced methods, like A*. But we need to fix Candidate ordering f I've heard that it is possible to use comonad approach to solve this problem however I couldn't find any example of this approach. +> test = solve testMap 5 1 + +as a result we will have [5,4,3,2,1]. That is correct solution.
 @@ -50,7 +50,7 @@ -

Basic algorithm

+

## Basic algorithm

The basic idea of our solution is: ‘we need to create a list of the locations that is reachable from initial location sorted by distance’. You can this about this solution like we move in all possible directions at the same time. Then we can filter out final destination and find history related to the correct solution.

Terms: frontier - a list of possible locations with distance from the starting point, sorted by ascending distance.

> type Frontier0 = [(Loc, Dist)]
@@ -85,9 +85,9 @@ And 4 with distance 5 will be moved to the result list (dashed). <> is a function that will merge and sort 2 lists. You can see result of the merge shown with dashed lines.
-

+

Now we can review types that we will use.

-

Candidate

+

### Candidate

All elements in a resulting set and a frontier are possible canditas for a solution, so they need to contain all temporary information (Distance) and information that we will need when we’ll filter out this solution (History). So we need to introduce a newtype for a candate, we use newtype here because we will need to redefine some properties otherwise we could use a tuple (,,):

> newtype Candidate = Candidate (Loc,Dist,History) deriving Eq   -- possible solution

And helper functions:

@@ -96,7 +96,7 @@ And 4 with distance 5 will be moved to the result list (dashed). > > candidateHist :: Candidate -> History > candidateHist (Candidate (_,_,x)) = x -

Ascending list

+

### Ascending list

As we have seen in the algorithm resulting list and frontier are ascending lists. So we may introduce special type that will preserve this property. This will help us to avoid additional mistakes, and can help with undestanding of our solution. This type is isomorphic to the List, however we can’t just use a newtype as we shouldn’t unpack pure list from the AscList:

> data AscList a = (:<) a (AscList a) | Nil

It’s easy to see that AscList forms a monoid with regard to concat operation, so we can use this information:

@@ -119,11 +119,11 @@ And 4 with distance 5 will be moved to the result list (dashed). > instance Ord Candidate where > compare (Candidate (_,d1,_)) (Candidate (_,d2,_)) = compare d1 d2

Now we can guarantee that lists are properly ordered.

-

Builder seed.

+

### Builder seed.

In order to create list we will use unfoldr :: (b -> Maybe (a, b)) -> b -> [a] combinator. On each step we will create one new element and return new seed. So we will need to store frontier in the seed. Additionaly we will use one optimization: we will store a list of visited locations (that exists in result array) and we will filter out locations that we have visited, so we need to store a set of location. So resulting type will look like:

> type Visited = Set Loc                  -- visited locations
> type Seed = (AscList Candidate,Visited) -- seed of the algorithm
-

Solver

+

## Solver

Now we are ready to introduce our solver:

> solve :: LMap       -- ^ map
>       -> Loc        -- ^ finish location
@@ -155,7 +155,9 @@ And 4 with distance 5 will be moved to the result list (dashed). >                     in Just ( Candidate (x,d,h)
>                               , (ls' <> xs, Set.insert x visited))

Yachoo! we have a solver. However it will work badly on the big maps and we need to use more advanced methods, like A*. But we need to fix Candidate ordering function.

-

I’ve heard that it is possible to use comonad approach to solve this problem however I couldn’t find any example of this approach.

]]> +

I’ve heard that it is possible to use comonad approach to solve this problem however I couldn’t find any example of this approach.

+
> test = solve testMap 5 1
+

as a result we will have [5,4,3,2,1]. That is correct solution.

]]> Сериализация структур данных в Haskell.<br/> Часть 1: типы данных
 @@ -50,7 +50,7 @@ -

Basic algorithm

+

## Basic algorithm

The basic idea of our solution is: ‘we need to create a list of the locations that is reachable from initial location sorted by distance’. You can this about this solution like we move in all possible directions at the same time. Then we can filter out final destination and find history related to the correct solution.

Terms: frontier - a list of possible locations with distance from the starting point, sorted by ascending distance.

> type Frontier0 = [(Loc, Dist)]
@@ -85,9 +85,9 @@ And 4 with distance 5 will be moved to the result list (dashed). <> is a function that will merge and sort 2 lists. You can see result of the merge shown with dashed lines.
-

+

Now we can review types that we will use.

-

Candidate

+

### Candidate

All elements in a resulting set and a frontier are possible canditas for a solution, so they need to contain all temporary information (Distance) and information that we will need when we’ll filter out this solution (History). So we need to introduce a newtype for a candate, we use newtype here because we will need to redefine some properties otherwise we could use a tuple (,,):

> newtype Candidate = Candidate (Loc,Dist,History) deriving Eq   -- possible solution

And helper functions:

@@ -96,7 +96,7 @@ And 4 with distance 5 will be moved to the result list (dashed). > > candidateHist :: Candidate -> History > candidateHist (Candidate (_,_,x)) = x -

Ascending list

+

### Ascending list

As we have seen in the algorithm resulting list and frontier are ascending lists. So we may introduce special type that will preserve this property. This will help us to avoid additional mistakes, and can help with undestanding of our solution. This type is isomorphic to the List, however we can’t just use a newtype as we shouldn’t unpack pure list from the AscList:

> data AscList a = (:<) a (AscList a) | Nil

It’s easy to see that AscList forms a monoid with regard to concat operation, so we can use this information:

@@ -119,11 +119,11 @@ And 4 with distance 5 will be moved to the result list (dashed). > instance Ord Candidate where > compare (Candidate (_,d1,_)) (Candidate (_,d2,_)) = compare d1 d2

Now we can guarantee that lists are properly ordered.

-

Builder seed.

+

### Builder seed.

In order to create list we will use unfoldr :: (b -> Maybe (a, b)) -> b -> [a] combinator. On each step we will create one new element and return new seed. So we will need to store frontier in the seed. Additionaly we will use one optimization: we will store a list of visited locations (that exists in result array) and we will filter out locations that we have visited, so we need to store a set of location. So resulting type will look like:

> type Visited = Set Loc                  -- visited locations
> type Seed = (AscList Candidate,Visited) -- seed of the algorithm
-

Solver

+

## Solver

Now we are ready to introduce our solver:

> solve :: LMap       -- ^ map
>       -> Loc        -- ^ finish location
@@ -155,7 +155,9 @@ And 4 with distance 5 will be moved to the result list (dashed). >                     in Just ( Candidate (x,d,h)
>                               , (ls' <> xs, Set.insert x visited))

Yachoo! we have a solver. However it will work badly on the big maps and we need to use more advanced methods, like A*. But we need to fix Candidate ordering function.

-

I’ve heard that it is possible to use comonad approach to solve this problem however I couldn’t find any example of this approach.

]]> +

I’ve heard that it is possible to use comonad approach to solve this problem however I couldn’t find any example of this approach.

+
> test = solve testMap 5 1
+

as a result we will have [5,4,3,2,1]. That is correct solution.

]]> Сериализация структур данных в Haskell.<br/> Часть 1: типы данных