I need a robust predicate defined by the following code:
CompareResult compareDistance(Point a, Point b, Point c, Point d) {
if (distance(a, b) > distance(c, d))
return Larger;
else if (distance(a, b) == distance(c, d))
return Equal;
else
return Smaller;
}
Due to the floating point arithmetic limitations we can't compute distance exactly (even its square), so if we just directly implement this code, the predicate will not be robust. I tried to find it in CGAL library, but couldn't.
Somewhat close to the predicate I need is compare_distance_to_point(Point p, Point q, Point r) predicate. It returns Smaller if distance(p, q) < distance(p, r), Equal if distance(p, q) == distance(p, r) and Larger otherwise. The first thought is to shift c and d by (c - a) vector, so we could call compare_distance_to_point(a, b, d + (c - a)), but this will violate robustness again. So, does anyone have an idea for adapting it?
If you take a kernel with exact predicates such as
Exact_predicates_inexact_constructions_kernel,
you can use the functor Compare_distance_3 which is a model of the concept CompareDistance_3.
Kernel::Compare_distance_3 cmp;
return cmp(a,b,c,d);
Related
I need to find a function P such that (using Beta - reduction)
P(g, h, i) ->* (h, i, i+1).
I am allowed to use the successor function succ. From wikipedia I got
succ = λn.λf.λx.f(n f x)
My answer is P = λx.λy.λz.yz(λz.λf.λu.f(z f u))z
but I'm not quite sure about it. My logic was the λx would effectively get rid of the g term, then the λy.λz would bring in the h and i via the yz. Then the succ function would bring in i+1 last. I just don't know if my function actually replicates this.
Any help given is appreciated
#melpomene points out that this question is unanswerable without a specific implementation in mind (e.g. for tuples). I am going to presume that your tuple is implemented as:
T = λabcf.f a b c
Or, if you prefer the non-shorthand:
T = (λa.(λb.(λc.(λf.f a b c))))
That is, a function which closes over a, b, and c, and waits for a function f to pass those variables.
If that is the implementation in mind, and assuming normal Church numerals, then the function you spec:
P(g, h, i) ->* (h, i, i+1)
Needs to:
take in a triple (with a, b, and c already applied)
construct a new triple, with
the second value of the old triple
the third value of the old triple
the succ of the third value of the old triple
Here is such a function P:
P = λt.t (λghi.T h i (succ i))
Or again, if you prefer non-shorthand:
P = (λt.t(λg.(λh.(λi.T h i (succ i)))))
This can be partially cleaned up with some helper functions:
SND = λt.t (λabc.b)
TRD = λt.t (λabc.c)
In which case we can write P as:
P = λt.T (SND t) (TRD t) (succ (TRD t))
I have this exam question:
Look at this example of pseudocode:
algorithm A(a, b) {
// precond: a & b are type of Int
// postcond: what does this function return?
if (a == b)
return( 0 )
else if (a < b)
return (-A(b, a))
else
return (A(a-1, b-1));
}
The answers given are:
a) a-b
b) a+b
c) max(a,b)
d) Will loop infinitely
Personally I think it's d), but I just wanted to make sure.
The function terminates when a==b; so to show that it doesn't terminate, you could show that a & b never get closer together with successive calls -- which in this case, is pretty easy.
(The above does not take into account overflow. Also, (d) can't be correct, since it doesn't loop at all.)
As long as a and b are not equal,
If a is less than b, the next function call would make a>b.
(For example calling A(3,4) would return -A(4,3) )
Subsequently, the function calls would result in an infinite recursion, as it keeps returning A(a-1, b-1) without termination.
(For example calling A(4,3) would return A(3,2) which would return A(2,1) and so on)
The only value the function will return is 0. And that's when a == b. But then, 0 = a - b for all (a,b) so that a == b. So I think the right answer is a).
I'm a beginner in Haskell, just started now learning about folds and what not, in college, first year.
One of the problems I'm facing now is to define Euclid's algorithm using the until function.
Here's the Euclid's recursive definition (EDIT: just to show how euclid works, I'm trying to define euclid's without the recursive. Just using until):
gcd a b = if b == 0 then a else gcd b (a `mod` b)
Here's what i have using until:
gcd a b = until (==0) (mod a ) b
Obviously this doesn't make any sense since it's always going to return 0, as that is my stopping point instead of printing the value of a when b == 0. I can't for the life of me though figure out how to get the value of a.
Any help is appreciated.
Thank you in advance guys.
Hints:
Now
until :: (a -> Bool) -> (a -> a) -> a -> a
so we need a function that we can apply repeatedly until a condition holds, but we have two numbers a and b, so how can we do that?
The solution is to make the two numbers into one value, (a,b), so think of gcd this way:
uncurriedGCD (a,b) = if b == 0 then (a,a) else uncurriedGCD (b,a `mod` b)
Now you can make two functions, next & check and use them with until.
Helpers for until:
next (a,b) = (b,a `mod` b)
check (a,b) = b == 0
This means that we now could have written uncurriedGCD using until.
Answer:
For example:
ghci> until check next (6,4)
(2,0)
ghci> until check next (12,18)
(6,0)
So we can define:
gcd a b = c where (c,_) = until check next (a,b)
giving:
ghci> gcd 20 44
4
ghci> gcd 60 108
12
What the Euclid's algorithm says is this: for (a, b), computing (b, mod a b) until (the new) b equals zero. This can be translated directly to an implementation using until like this:
myGcd a b = until (\(x, y) -> y == 0) (\(x, y) -> (y, x `mod` y)) (a, b)
Can anyone explain why these two statements aren't equal?
if not(a and not b):
// do some stuff
if (not a and b):
// do some stuff
I tried to make my program more understandable by changing the first statement to the second but it doesn't work. I don't totally understand why.
You should look into De Morgan's Thereom, half of which is (a):
not(p and q) -> not(p) or not(q)
In terms of how that applies to your situation, just replace p with a and q with not(b):
not(a and not b) -> not(a) or not(not(b))
-> not(a) or b
(a) The other half is:
not(p or q) -> not(p) and not(q)
if not(a and not b) is the same as if (not a) or b, not what you wrote.
You also need to flip the 'and' to 'or' due to De Morgan's law
if not(a and not b)
becomes
if (not a or b)
I am self-studying Okasaki's Purely Functional Data Structures, now on exercise 3.4, which asks to reason about and implement a weight-biased leftist heap. This is my basic implementation:
(* 3.4 (b) *)
functor WeightBiasedLeftistHeap (Element : Ordered) : Heap =
struct
structure Elem = Element
datatype Heap = E | T of int * Elem.T * Heap * Heap
fun size E = 0
| size (T (s, _, _, _)) = s
fun makeT (x, a, b) =
let
val sizet = size a + size b + 1
in
if size a >= size b then T (sizet, x, a, b)
else T (sizet, x, b, a)
end
val empty = E
fun isEmpty E = true | isEmpty _ = false
fun merge (h, E) = h
| merge (E, h) = h
| merge (h1 as T (_, x, a1, b1), h2 as T (_, y, a2, b2)) =
if Elem.leq (x, y) then makeT (x, a1, merge (b1, h2))
else makeT (y, a2, merge (h1, b2))
fun insert (x, h) = merge (T (1, x, E, E), h)
fun findMin E = raise Empty
| findMin (T (_, x, a, b)) = x
fun deleteMin E = raise Empty
| deleteMin (T (_, x, a, b)) = merge (a, b)
end
Now, in 3.4 (c) & (d), it asks:
Currently, merge operates in two
passes: a top-down pass consisting of
calls to merge, and a bottom-up pass
consisting of calls to the helper
function, makeT. Modify merge to
operate in a single, top-down pass.
What advantages would the top-down
version of merge have in a lazy
environment? In a concurrent
environment?
I changed the merge function by simply inlining makeT, but I fail to see any advantages, so I think I haven't grasped the spirit of these parts of the exercise. What am I missing?
fun merge (h, E) = h
| merge (E, h) = h
| merge (h1 as T (s1, x, a1, b1), h2 as T (s2, y, a2, b2)) =
let
val st = s1 + s2
val (v, a, b) =
if Elem.leq (x, y) then (x, a1, merge (b1, h2))
else (y, a2, merge (h1, b2))
in
if size a >= size b then T (st, v, a, b)
else T (st, v, b, a)
end
I think I've figured out one point with regards to lazy evaluation. If I don't use the recursive merge to calculate the size, then the recursive call won't need to be evaluated until the child is needed:
fun merge (h, E) = h
| merge (E, h) = h
| merge (h1 as T (s1, x, a1, b1), h2 as T (s2, y, a2, b2)) =
let
val st = s1 + s2
val (v, ma, mb1, mb2) =
if Elem.leq (x, y) then (x, a1, b1, h2)
else (y, a2, h1, b2)
in
if size ma >= size mb1 + size mb2
then T (st, v, ma, merge (mb1, mb2))
else T (st, v, merge (mb1, mb2), ma)
end
Is that all? I am not sure about concurrency though.
I think you've essentially got it as far as the lazy evaluation goes -- it's not very helpful to use lazy evaluation if you are going to have to end up traversing the whole data structure to find out anything every time you do a merge...
As to the concurrency, I expect the issue is that if, while one thread is evaluating the merge, another comes along and wants to look something up, it will not be able to get anything useful done at least until the first thread completes the merge. (And it might even take longer than that.)
It doesn’t any benefit to WMERGE-3-4C function in a lazy environment. It still does all the work that the original down-up merge did. It pretty sure it would not be any easier for the language system to memorize..
No benefit to WMERGE-3-4C functions in a concurrent environment. Each call to WMERGE-3-4C does all its work before passing the buck to another instance of WMERGE-3-4C. In fact, if we eliminated the recursion by hand, WMERGE-3-4C could be implemented as a single loop that does all the work while accumulating a stack, then a second loop that does the REDUCE work on the stack. The first loop would not be naturally parallizable, though maybe the REDUCE could operate by calling the function on pairs, in parallel, until only one element remained in the list.