- Haskell-Cafe - Haskell.org

Re: [Haskell-cafe] HUnit and table-driven tests
by Matthew 07 Aug '12

07 Aug '12

On Tue, Aug 7, 2012 at 12:51 AM, Dean Herington <heringtonlacey(a)mindspring.com> wrote: > At 4:30 PM -0700 8/5/12, Matthew wrote: >> >> On Sun, Aug 5, 2012 at 12:32 AM, Henk-Jan van Tuyl <hjgtuyl(a)chello.nl> >> wrote: >>> >>> On Sun, 05 Aug 2012 03:21:39 +0200, Matthew <wonderzombie(a)gmail.com> >>> wrote: >>> >>>> I've got a function which takes in two chars, describing a playing >>>> card and a suit. An example would be 4C or TH for a 4 of Clubs or a >>>> Ten of Hearts. I need to be able to compare the ranks of a card (e.g. >>>> a King is 13), so a Card is a tuple of rank and suit. The function >>>> which parses a Card is type String -> Maybe Card. >>>> >>>> I'm writing unit tests for this using HUnit, and ideally I'd go with a >>>> table-driven[1] approach, where each test case is a tuple of the input >>>> and the expected output. (Possibly I could expand this to a triple, or >>>> simply a list, to allow for an error message for each test case.) Then >>>> all the test function has to do is run through each case and assert as >>>> necessary. Example: [("TH", Just (Hearts, 10)), ("XH", Nothing)]. >>> >>> >>> >>> A simple solution: >>> >>>> parseCard :: String -> Maybe Card >>>> parseCard string = <your function to test> >>>> test :: Bool >>>> test = all testEqual [("TH", Just (Hearts, 10)), ("XH", Nothing)] >>>> where >>>> testEqual (input, output) = parseCard input == output >>> >>> >>> >>> For a description of 'all', see: >>> >>> >>> http://hackage.haskell.org/packages/archive/base/latest/doc/html/Prelude.ht… >> >> >> Thanks for the response. The one problem I have with this is that it >> will not be at all obvious which test case (or cases!) failed. >> >> That said, maybe I could do something similar, with a Writer? A passed >> test writes "", but a failed one writes a test-specific failure >> message. Then the test itself uses this string as the assert message. > > > > Let HUnit tell you about the failing test cases. Here's one way to do it. > > > import Test.HUnit > import Data.Char (isDigit) > > data Suit = Spades | Hearts | Diamonds | Clubs > deriving (Show, Read, Eq, Ord) > type Rank = Int -- 2 .. 14 (jack=11, queen=12, king=13, ace=14) > type Card = (Suit, Rank) > > > parseCard :: String -> Maybe Card > parseCard [rankChar, suitChar] = do suit <- suitFrom suitChar; rank <- > rankFrom rankChar; return (suit, rank) > parseCard _ = Nothing > > suitFrom char = lookup char [('S', Spades), ('H', Hearts), ('D', Diamonds), > ('C', Clubs)] > > rankFrom dig | isDigit dig = let v = read [dig] in if v >= 2 then Just v > else Nothing > rankFrom char = lookup char [('T', 10), ('J', 11), ('Q', 12), ('K', 13), > ('A', 14)] > > makeTest :: (String, Maybe Card) -> Test > makeTest (string, result) = string ~: result ~=? parseCard string > > tests = [("TH", Just (Hearts, 10)), ("XH", Nothing)] > > main = (runTestTT . TestList . map makeTest) tests ...it seems so obvious now. This is *exactly* what I was looking for; clearly I was over-thinking this. Thanks, Dean! > > > Dean

1 0

Benchmark of DFT libraries in Haskell
by Takayuki Muranushi 07 Aug '12

07 Aug '12

Dear everyone, I'm always grateful to your help. I have been assigned a complicated and growing task in which I'll perform a lot of discrete Fourier transforms, so I have measured performance of several DFT libraries in Haskell: http://en.pk.paraiso-lang.org/Hackage/what-is-the-fastest-dft-in-haskell/ma… The raw result: http://paraiso-lang.org/html/bench-dft-in-haskell.html I'll share the result in hope that some of you will also find this result useful. Also, please let me know any possible flaws or improvements in the benchmark process! My observations are as follows: * vector-fftw with wisdom was more than 1/2 times faster than fftw in C with wisdom (and with communication overhead.) * vector-fftw without wisdom was significantly _faster_ than fftw in C without wisdom. I wonder why. * vector-fftw over vector was faster than fft over CArray. * any library that doesn't use fftw is much slower than those that does. Best, -- Takayuki MURANUSHI The Hakubi Center for Advanced Research, Kyoto University http://www.hakubi.kyoto-u.ac.jp/02_mem/h22/muranushi.html

4 6

ANNOUNCE: tardis
by Dan Burton 07 Aug '12

07 Aug '12

I'm pleased to announce that I've uploaded the *tardis* package to hackage. http://hackage.haskell.org/package/tardis-0.2.0.0 *TardisT* is a monad transformer that combines the (regular, "forwards") State monad with the "backwards State monad", allowing you to communicate on two channels of state: one is "backwards travelling" state, while the other is "forwards travelling" state. Its primitives are comparable to the State monad's "get" and "put", but the names disambiguate which channel they operate on: getPast :: Monad m => TardisT bw fw m fw getFuture :: Monad m => TardisT bw fw m bw sendPast :: Monad m => bw -> TardisT bw fw m () sendFuture :: Monad m => fw -> TardisT bw fw m () These primitives allow you to write some very amusing timey-wimey code, but it only works in the presence of sufficient laziness. If you run into an infinite loop, try adding laziness annotations everywhere, and make sure that what you are trying to do is not a time paradox. I've provided both *transformers* and *mtl* style modules: Control.Monad.Trans.Tardis contains the transformer, while Control.Monad.Tardis.Class contains the MonadTardis class, and Control.Monad.Tardis re-exports both as well as the TardisT instance for MonadTardis. See the readme on github for more details: https://github.com/DanBurton/tardis#readme As a side note, since the code base is relatively small, it can also serve as a simple demonstration of how to use a cabal flag in conjunction with CPP to selectively include swaths of code (see Control/Monad/Tardis.hs and tardis.cabal). I'm not entirely sold on the naming conventions for the package (including the package name), and am open to suggestions. -- Dan Burton

2 1

HUnit and table-driven tests
by Matthew 07 Aug '12

07 Aug '12

I've got a function which takes in two chars, describing a playing card and a suit. An example would be 4C or TH for a 4 of Clubs or a Ten of Hearts. I need to be able to compare the ranks of a card (e.g. a King is 13), so a Card is a tuple of rank and suit. The function which parses a Card is type String -> Maybe Card. I'm writing unit tests for this using HUnit, and ideally I'd go with a table-driven[1] approach, where each test case is a tuple of the input and the expected output. (Possibly I could expand this to a triple, or simply a list, to allow for an error message for each test case.) Then all the test function has to do is run through each case and assert as necessary. Example: [("TH", Just (Hearts, 10)), ("XH", Nothing)]. The problem, of course, is that I've no clue how to make this work. I still don't *quite* grok do notation well enough to understand how I can bind a monadic value (in this case a Maybe Card), pattern match on such as the Integer in there, and then assertEqual. I suspect I'm just thinking about this all wrong. Any suggestions? Thanks again! [1]: http://code.google.com/p/go-wiki/wiki/TableDrivenTests

3 3

ANNOUNCE: system-time-monotonic-0.1
by Joey Adams 06 Aug '12

06 Aug '12

system-time-monotonic [1] provides access to the system's monotonic clock. Usage looks like this: * Use 'newClock' to create a new monotonic clock * Use 'clockGetTime' to see how much time has elapsed since the clock was created. This package currently supports Linux and Windows. It might also work on BSD, but I haven't tested it there. Mac OS X support is currently not implemented, but patches are welcome. GHC uses mach_absolute_time and mach_timebase_info; see ticket #5865 [2]. I also added a handy utility function 'delay', a variant of threadDelay taking a DiffTime instead of Int microseconds. Thus: delay 1.5 Waits 1.5 seconds. Note that since 'delay' simply calls 'threadDelay' in a loop, it is disrupted by system clock changes (again, see ticket #5865). [1]: http://hackage.haskell.org/package/system-time-monotonic [2]: http://hackage.haskell.org/trac/ghc/ticket/5865 --- The rest of this email describes various hurdles involved in implementing this package, and how they were addressed. ## GetTickCount The most obvious one is that GetTickCount has a short wraparound (49.7 days). Two ways to address this: * Don't use GetTickCount; use QueryPerformanceCounter (or similar) instead. This is currently how it's done in GHC HEAD. * Use GetTickCount, but avoid comparing times that are far apart by tracking the total difference each time we look at the clock. I took the second approach, because I found out that QueryPerformanceCounter is actually less accurate in the long run than GetTickCount. In particular, QueryPerformanceCounter stops ticking (or maybe ticks slower, I forget) when the computer is asleep. Here's the trick I use to work around GetTickCount's wraparound (pseudocode): st1 :: Word32 t1 :: DiffTime newClock: st1 := GetTickCount() t1 := 0 clockGetTime: st2 := GetTickCount() t2 := t1 + (Int32)(st2 - st1 modulo 2^32) st1 := st2 t1 := t2 return t2 This workaround only works if clockGetTime is called at least once every 24.8 days. It's important that st2 - st1 be done modulo 2^32, to compensate for wraparound. However, the result should be converted to a signed 32-bit integer, in case st2 was recorded earlier than st1 (which can easily happen in a concurrent context). In particular, here's what you should *not* do (which GHC currently does, when QueryPerformanceCounter is not available): st1 = (bigger_type) GetTickCount(); ... st2 = (bigger_type) GetTickCount(); return (st2 - st1) This will return a bogus value if a wraparound occurred between st1 and st2. system-time-monotonic tests, at runtime, if GetTickCount64 is available. If so, it uses it. Otherwise, it falls back to GetTickCount. Here's the code I used to do the run-time system call lookup: /* cbits/dll.c */ typedef ULONGLONG (WINAPI *GetTickCount64_t)(void); GetTickCount64_t system_time_monotonic_load_GetTickCount64(void) { return (GetTickCount64_t) GetProcAddress(GetModuleHandle(TEXT("kernel32.dll")), "GetTickCount64"); } -- System/Time/Monotonic/Direct.hsc type C_GetTickCount64 = IO #{type ULONGLONG} foreign import ccall system_time_monotonic_load_GetTickCount64 :: IO (FunPtr C_GetTickCount64) foreign import stdcall "dynamic" mkGetTickCount64 :: FunPtr C_GetTickCount64 -> C_GetTickCount64 Did I do this right? In particular: * Can I assume the kernel32.dll HMODULE won't be pulled out from under me? * Is `foreign import stdcall "dynamic"` the right incantation for using a pointer to a WINAPI function? ## CLOCK_MONOTONIC is not actually monotonic on Linux CLOCK_MONOTONIC is subject to NTP adjustments. Worse, CLOCK_MONOTONIC stops when the computer is put to sleep (unlike GetTickCount, which does the right thing). Two clocks were introduced very recently in Linux: * CLOCK_MONOTONIC_RAW * CLOCK_BOOTTIME I'd like to support CLOCK_BOOTTIME at some point. I'm not sure if it's subject to NTP adjustments or not, since the announcement [3] says: CLOCK_BOOTTIME is identical to CLOCK_MONOTONIC, except it also includes any time spent in suspend (as currently measured by read_persistent_clock()). This allows applications to get a suspend aware monotonic clock. One idea would be to hard-code the clockid_t of CLOCK_BOOTTIME and CLOCK_MONOTONIC_RAW, and try calling clock_gettime with each of these. If one of these succeeds, use it. Otherwise, fall back to CLOCK_MONOTONIC. Thus, the compiled binary can test, at runtime, if a new enough kernel is available. For now, system-time-monotonic simply uses CLOCK_MONOTONIC. [3]: http://lwn.net/Articles/428176/

1 0

Re: [Haskell-cafe] CRIP: the Curiously Reoccuring Instance Pattern
by oleg＠okmij.org 06 Aug '12

06 Aug '12

> I think instead you should have: > - abandoned FunDeps > - embraced Overlapping more! Well, using TypeCast to emulate all FunDeps was demonstrated three years later after HList (or even sooner -- I don't remember when exactly the code was written): http://okmij.org/ftp/Haskell/TypeClass.html#Haskell1 We demonstrate that removing from Haskell the ability to define typeclasses leads to no loss of expressivity. Haskell restricted to a single, pre-defined typeclass with only one method can express all of Haskell98 typeclass programming idioms including constructor classes, as well as multi-parameter type classes and even some functional dependencies. The addition of TypeCast as a pre-defined constraint gives us all functional dependencies, bounded existentials, and even associated data types. Besides clarifying the role of typeclasses as method bundles, we propose a simpler model of overloading resolution than that of Hall et al. > So here's my conjecture: > 1. We don't need FunDeps, except to define TypeCast. > (And GHC now has equality constraints, which are prettier.) > 2. Without FunDeps, overlapping works fine. > ... I agree on point 1 but not on point 2. The example of incoherence described in Sec `7.6.3.4. Overlapping instances' of the GHC User Guide has nothing to do with functional dependencies.

2 2

Knight Capital debacle and software correctness
by Vasili I. Galchin 06 Aug '12

06 Aug '12

Hello Haskell Group, I work in mainstream software industry. I am going to make an assumption .... except for Jane Street Capital all/most "Wall Street" software is written in an imperative language. Assuming this why is Wall Street not awaken to the dangers. As I write, Knight Capital may not survive the weekend. Regards, Vasili

9 12

Talk about Haskell at Ubucon in Berlin
by Robert Clausecker 05 Aug '12

05 Aug '12

Hello Haskellers! I'm going to give a talk on Haskell at Ubucon 2012 in Berlin (In German). I want to give an introduction about the concept of functional programming and the special language concepts of Haskell. Any ideas what to focus on? Yours, Robert Clausecker

2 1

Sorting efficiency
by David Feuer 05 Aug '12

05 Aug '12

I'm writing a toy program (for a SPOJ problem--see https://www.spoj.pl/problems/ABCDEF/ ) and the profiler says my performance problem is that I'm spending too much time sorting. I'm using Data.List.sort on [Int32] (it's a 32-bit architecture). Others, using other languages, have managed to solve the problem within the time limit using the same approach I've taken (I believe), but mine is taking too long. Any suggestions? Do I need to do something insane like sorting in an STUArray? David Feuer

3 5

do vs. pattern matching
by Matthew 05 Aug '12

05 Aug '12

I'm a somewhat experienced coder but I am relatively new to Haskell. I've got a question about whether a usage of do notation is idiomatic, or whether it's better to use pattern matching. I've got two functions which take an input and return Maybe SomeType. If either returns Nothing, I also want to return Nothing. If they both return something, then I'll return something unrelated. With do notation, I can write something like this: do foo <- callFoo x bar <- callBar x return (baz) Alternatively, there's a straightforward pattern match. After binding foo, bar in a couple of where clauses: case (foo,bar) of (Just x, Just y) -> baz _ -> Nothing So which approach is more idiomatic, do you think? Thanks, - Matthew

5 5