condda / softwaretestingft_g Goto Github PK

triangle could be simplified by sorting the nodes before you check some of the formulae. This can be done by a very simple clause in the lines of …where [x,y,z] = sort [a,b,c].

Tests for triangle sometimes have quite an overlap with the function definition (and in this case, what are you really testing?), but very neatly organised.

Why do you need dropOne? Isn’t it just tail?

Your flatten is just foldr (++) [], why do you have a lengthy recursive definition?

perms (a:[]) = [[a]]

What does this mean? Isn’t a:[] just [a]? What happened to the nice code of last week, did you lose your Haskell mojo?

-- MEMO TO SELF: I HATE MONADS! AVOID THEM WHENEVER POSSIBLE!

A monad is just a monoid object in a category of endofunctors.

-- We found the following function:
numberOfDerangements :: Int -> Int
numberOfDerangements 1 = 1
numberOfDerangements x | even x = (numberOfDerangements (x-1) ) * (x-1) - 1
                       | otherwise  = (numberOfDerangements (x-1) ) * (x-1) + 1

I’m glad you found this function, but it’s not the right function to answer this question, which is easily established by running a couple of tests by comparing it to length.deran.

-- ALL WORKS, INCLUDING SOME RANDOM TESTING, BUT 2 MINUTES BEFORE 12PM, THIS FUNCTION IS THE ONLY ONE LEFT!!
-- HOWEVER, THIS FUNCTION IS TRIVIAL!
-- testDerLsts = do
--   x <- [ testDerLst n | n <- [0..100] ]
--   return $ (allTrue x)

This does not type check: your testDerLst returns a monad, so what you have in x is a list of monads (ewww!), but your allTrue takes a list of Booleans. When you fix these problems, you still have another one that your derLst does not work on smaller lists:

*Bonus1> derLst []
*** Exception: Prelude.(!!): negative index

*Bonus1> derLst [1]
^CInterrupted.
*Bonus1> derLst [1,2]
[2,1]
*Bonus1> 

which means that n <- [2..100] would actually return True, but if you start with zero you get an exception and if you start with 1 your test hangs (because it keeps looking for something that does not exist).

Unfortunately it seems like neither of the bonus solutions work correctly, but you do get a solid +.

list_max [] = error "No max from emptry list"

emptry? Seriously?

Wow, you used the “dot” operator, (.).(.). Impressive! I wasn’t expecting to see advanced Haskell in the first week.

my_length = foldr (\_ x -> succ x) 0

This is the exact opposite of advanced Haskell ;) This should be η-reduced at least to my_length = foldr (const succ) 0.

my_map f = foldr (\x y -> (f x) : y) [] 

Again, why not foldr ((:) . f) []?

-- foldr is uses lazy eveluation, for example

is uses? eveluation? Come on, be a bit serious about words you are writing!

Take this ++ for the first week and carry it with pride.

equiv' :: [Valuation] -> Form -> Form -> Bool
equiv' [] f1 f2 = True
equiv' (v:vs) f1 f2 = (eval v f1) == (eval v f2) && (equiv' vs f1 f2)

equiv :: Form -> Form -> Bool
equiv f1 f2 = (equiv' (allVals (Cnj [f1, f2])) f1 f2)

Hmm... Were you not the ones who were writing the code for tautology a couple of lines before that! Y U NO REUSE?

The CNF normalisation is a bit chaotic (several functions where one would suffice, misleading names of functions, etc), but appears to be correct.

Converting to clause form is also okay. I personally think that a healthy mix of map and concat would have made a shorter and a more readable solution, but foldr works apparently as well.

The DPLL thing is very cool! On my machine the testing sometimes hangs, but I could not point out why and if it is really stuck or just doing some stuff in the background (in particular, Prop 8 seems to be an unlucky case, but running it manually works perfectly). The algorithm itself, as far as I can assess, is correct or close to being correct, so here’s a ++ for you!

Ex.1: Test.QuickCheck.Monadic, wow!

-- Also test if the 

Never leave comments unf

Ex.2: Nice concise solution, nice report.

Ex.3: by hacking into the nodes of the search tree, you tweak the search algorithm, not the solution, so in this case it's also possible to make it admit that even a “solution” with nine empty blocks is a perfect and a unique solution (because according to your constraints, the empty blocks are unfillable). Your next error is the use of rsolveNs: you basically take a rigged search tree node, take a random solution out of it and then check if that totally random solution cannot be solved differently. Well, of course it cannot: any complete solution would be a unique solution for itself, and you maliciously remove all possibly falsifiable constraints beforehand. The process just cannot go wrong, the way you programmed it, and will always give positive results to anything.

*Lab5> do [r] <- rsolveNs [emptyN] ; print $ uniqueSol r
True

Yay, I have proven that a completely empty sudoku has a unique solution!

*Lab5> uniqueSol (\ _ -> 0, [])
True

Yay, I have proven that an empty and impossible to fill sudoku has a unique solution!

This is not a solution, this is madness.

Ex.4&5: seem to be correct. I needed to write my own code to check it, and it seems it’s slow as ever, but hey, who needs speed.

Ex.6: at first (after waiting a couple of minutes of runtime) I thought this is a killer for those who thought previous solutions were slow, but then I took an arrow to the knee:

classivie n = if x > 15 then 15 else (if x < 10 then 15 else 10)

This is your code. And this is what you do with your code:

  if (classivie node) == 5 then showNode node else easy_one

So let me try to describe it... you have defined a function that returns either 15 or 10 and you’re waiting for it to return 5. Suuuuure.

There are other problems with your code: for example, stats by definition always return [], which turns average into a constant NaN, which pretty much ensures classivie will always stay at ten, yet you have two “generators” which wait for 5 and 15...

Am I missing something here?

The bonus exercise kinda works, even though it is left untested/unspecd, and solveExSudoku should have used solveNs (not rsolveNs).

This is definitely a +, perhaps a bit more than an average plus, but with two big holes in the non-bonus exercises I cannot really settle on a higher grade.

Glad to know you understands absolutely everything covered so far and do not have any questions. Must get back to the exam draft to make it more challenging...

I found the word "transative" in the PDF. Twice. How can you explain that?

Ex.3 seems nicely done, perhaps the best code I’ve seen so far for this task.

Ex.4 has much less though behind it: the union is too brutal (it works, sure...), the other two are very traditionalistically recursive. Could there be a sweet spot in the middle ground, something filter-based perhaps?

-- Not only QuickCheck, but also HSpec!

;)

Ex.5: Yes! Finally a fixpoint-based trClose implementation, I have lived long enough to see it!

Ex.8: correct (even though I would have preferred to see the actual proof, perhaps just by working out the formula to surface the root/square — but I believe you can do that). Be more convincing at the exam!

This is a ++.