From c9f136782524084ecc89b2f190ab92ff3feb25d7 Mon Sep 17 00:00:00 2001 From: Camil Staps Date: Thu, 21 Apr 2016 20:14:02 +0200 Subject: Removed stuff --- .gitignore | 4 ++++ opdracht1.tex | 64 ------------------------------------------------- opdracht1/opdracht1.tex | 64 +++++++++++++++++++++++++++++++++++++++++++++++++ tryouts/fold.icl | 40 +++++++++++++++++++++++++++++++ 4 files changed, 108 insertions(+), 64 deletions(-) delete mode 100644 opdracht1.tex create mode 100644 opdracht1/opdracht1.tex create mode 100644 tryouts/fold.icl diff --git a/.gitignore b/.gitignore index 981ca62..23b0057 100644 --- a/.gitignore +++ b/.gitignore @@ -28,3 +28,7 @@ *.synctex.gz _minted-*/ +### Clean +Clean\ System\ Files/ +a.out + diff --git a/opdracht1.tex b/opdracht1.tex deleted file mode 100644 index 2ba6a5e..0000000 --- a/opdracht1.tex +++ /dev/null @@ -1,64 +0,0 @@ -\documentclass[a4paper]{article} - -\usepackage[dutch]{babel} -\usepackage{geometry} - -\title{Academisch Schrijven\\\large{Opdracht 1}} -\author{Camil Staps} - -\begin{document} - -\maketitle - -\section*{Lezerspubliek} -Doordat we weinig jargon en geen vakspecifieke afkortingen gebruiken -is onze review leesbaar voor een groot publiek. Wel hebben we enkele aannames -gemaakt: we gaan er van uit dat de lezer bekend is met het fenomeen -`vakantie plannen' en dat hij een globaal idee heeft wat de mogelijkheden -van Android apps zijn. Deze aannames zijn vandaag de dag triviaal. - -De reden waarom mensen deze review zouden willen lezen kan verschillen. De -voor de hand liggende reden is natuurlijk dat de lezer op zoek is naar een app -die kan helpen bij het plannen van een vakantie. Een andere mogelijkheid is -dat de lezer ge\"interesseerd is in verschillende methodes voor usability -onderzoek. Voor het eerste type lezer is de uitweiding over de -onderzoeksmethode wellicht overbodig, ook al kan die, wanneer de lezer enig -gevoel voor de wetenschappelijke methode heeft, wel helpen een idee te geven -van de betrouwbaarheid van de gevonden resultaten. Het tweede type lezer zal -minder ge\"interesseerd zijn in de de concrete toepassing van de methode, -alhoewel die nog wel als voorbeeld kan dienen. - -Het artikel is niet geschikt voor het tweede type lezer als die al een -redelijke kennis van usability onderzoek heeft, omdat onze review weinig -diepgaand is. - -\section*{Suggesties voor verbetering} -\begin{itemize} - \item De inleiding is vrij lang en bevat meer dan de strikt noodzakelijke - situatie. Met de ervaring die ik nu wel heb, maar toen niet had, weet ik - dat het prettig is als inleiding zo beknopt mogelijk beschrijven waar het - artikel over gaat, zodat de zoektocht naar een relevant paper effici\"ent - is. Teksten als `Bij het plannen van een vakantie komt veel kijken' zijn - eigenlijk overbodig. Ik zou de inleiding dus willen verkorten tot het - strikt noodzakelijke. - - \item De opsomming van testdoelen hoort eigenlijk niet thuis in de - inleiding en moet in een aparte sectie. Ook is de opmaak van dit - deel wat ongelukkig: er is onnodig veel witruimte. Ik zou nu liever de - \texttt{description}-omgeving of een simpele genummerde lijst gebruiken. - - \item De kopjes `Scenario $n$' zijn weinig beschrijvend. Door - hier betekenisvolle namen te gebruiken zou je het makkelijker kunnen - maken later informatie terug te vinden. -\end{itemize} - -Waar ik wel tevreden over ben is de algehele opbouw van de tekst. De -informatie komt in de volgorde die de lezer verwacht en nodig heeft. Ook -leest de conclusie prettig door het benadrukken van steekwoorden. De -indeling van suggesties in de laatste sectie geeft naast een rangorde ook -direct een waardering van elke suggestie (niet alleen een relatieve maar ook -een absolute indicatie van de zwaarte van het probleem), wat het makkelijker -maakt de nodige informatie uit de tekst te halen. - -\end{document} - diff --git a/opdracht1/opdracht1.tex b/opdracht1/opdracht1.tex new file mode 100644 index 0000000..2ba6a5e --- /dev/null +++ b/opdracht1/opdracht1.tex @@ -0,0 +1,64 @@ +\documentclass[a4paper]{article} + +\usepackage[dutch]{babel} +\usepackage{geometry} + +\title{Academisch Schrijven\\\large{Opdracht 1}} +\author{Camil Staps} + +\begin{document} + +\maketitle + +\section*{Lezerspubliek} +Doordat we weinig jargon en geen vakspecifieke afkortingen gebruiken +is onze review leesbaar voor een groot publiek. Wel hebben we enkele aannames +gemaakt: we gaan er van uit dat de lezer bekend is met het fenomeen +`vakantie plannen' en dat hij een globaal idee heeft wat de mogelijkheden +van Android apps zijn. Deze aannames zijn vandaag de dag triviaal. + +De reden waarom mensen deze review zouden willen lezen kan verschillen. De +voor de hand liggende reden is natuurlijk dat de lezer op zoek is naar een app +die kan helpen bij het plannen van een vakantie. Een andere mogelijkheid is +dat de lezer ge\"interesseerd is in verschillende methodes voor usability +onderzoek. Voor het eerste type lezer is de uitweiding over de +onderzoeksmethode wellicht overbodig, ook al kan die, wanneer de lezer enig +gevoel voor de wetenschappelijke methode heeft, wel helpen een idee te geven +van de betrouwbaarheid van de gevonden resultaten. Het tweede type lezer zal +minder ge\"interesseerd zijn in de de concrete toepassing van de methode, +alhoewel die nog wel als voorbeeld kan dienen. + +Het artikel is niet geschikt voor het tweede type lezer als die al een +redelijke kennis van usability onderzoek heeft, omdat onze review weinig +diepgaand is. + +\section*{Suggesties voor verbetering} +\begin{itemize} + \item De inleiding is vrij lang en bevat meer dan de strikt noodzakelijke + situatie. Met de ervaring die ik nu wel heb, maar toen niet had, weet ik + dat het prettig is als inleiding zo beknopt mogelijk beschrijven waar het + artikel over gaat, zodat de zoektocht naar een relevant paper effici\"ent + is. Teksten als `Bij het plannen van een vakantie komt veel kijken' zijn + eigenlijk overbodig. Ik zou de inleiding dus willen verkorten tot het + strikt noodzakelijke. + + \item De opsomming van testdoelen hoort eigenlijk niet thuis in de + inleiding en moet in een aparte sectie. Ook is de opmaak van dit + deel wat ongelukkig: er is onnodig veel witruimte. Ik zou nu liever de + \texttt{description}-omgeving of een simpele genummerde lijst gebruiken. + + \item De kopjes `Scenario $n$' zijn weinig beschrijvend. Door + hier betekenisvolle namen te gebruiken zou je het makkelijker kunnen + maken later informatie terug te vinden. +\end{itemize} + +Waar ik wel tevreden over ben is de algehele opbouw van de tekst. De +informatie komt in de volgorde die de lezer verwacht en nodig heeft. Ook +leest de conclusie prettig door het benadrukken van steekwoorden. De +indeling van suggesties in de laatste sectie geeft naast een rangorde ook +direct een waardering van elke suggestie (niet alleen een relatieve maar ook +een absolute indicatie van de zwaarte van het probleem), wat het makkelijker +maakt de nodige informatie uit de tekst te halen. + +\end{document} + diff --git a/tryouts/fold.icl b/tryouts/fold.icl new file mode 100644 index 0000000..26967d2 --- /dev/null +++ b/tryouts/fold.icl @@ -0,0 +1,40 @@ +module fold + +import StdEnv + +:: List a = Nil | Cons a (List a) + +(~>) infixr 4 :: (a (List a) -> List a) +(~>) = Cons + +foldr :: (a -> b -> b) b (List a) -> b +foldr f x Nil = x +foldr f x (Cons a l) = f a (foldr f x l) + +map :: (a -> b) -> (List a) -> (List b) +map f = foldr (Cons o f) Nil + +sum = foldr (+) zero +product = foldr (*) one + +any = foldr (||) False +all = foldr (&&) True + +copy = foldr Cons Nil +append a b = foldr Cons b a +length = foldr (\_ n -> n + 1) 0 + +:: Tree a = Node a (List (Tree a)) + +(@) infixr 4 :: (a (List (Tree a)) -> Tree a) +(@) = Node + +foldtree :: (a -> b -> c) (b -> c -> b) b (Tree a) -> c +foldtree f g a (Node l ts) = f l (foldtree` f g a ts) +where + //foldtree` :: (a -> b -> c) (c -> b -> b) b (List (Tree a)) -> b ?? + foldtree` f g a (Cons t r) = g (foldtree f g a t) (foldtree` f g a r) + foldtree` f g a Nil = a + +Start = map ((*)2) (5 ~> 10 ~> Nil) + -- cgit v1.2.3