Bizarre Haskell Problem
Hello, I am having a bizarre Haskell problem that I am having difficulty debugging. I am not positive this is a compiler problem, but my results are not making any sense. I have attached a few source files which compiled with ghc-5.04.2 running under Win95. The files were compiled as: ghc -c DFT.lhs ghc -c FFT1.lhs ghc -c FFT2.lhs ghc -c Main1.hs ghc -c Mail2.hs ghc -o test1 Main1.o FFT1.o DFT.o ghc -o test2 Main2.o FFT2.o DFT.o Running test1 gives the following results (the last line is wrong): foo 19:[1,2,4,8,16,13,7,14,9,18,17,15,11,3,6,12,5,10] rader1 19: [1,2,4,8,16,13,7,14,9,18,17,15,11,3,6,12,5,10] foo 23:[1,5,2,10,4,20,8,17,16,11,9,22,18,21,13,19,3,15,6,7,12,14] rader1 23: [1,5,2,10,4,20,8,17,16,11,9,22,18,21,1,4,8,18,22,6,19,2] Running test2 gives the following results (these are the results I expect): foo 19:[1,2,4,8,16,13,7,14,9,18,17,15,11,3,6,12,5,10] rader1 19: [1,2,4,8,16,13,7,14,9,18,17,15,11,3,6,12,5,10] foo 23:[1,5,2,10,4,20,8,17,16,11,9,22,18,21,13,19,3,15,6,7,12,14] rader1 23: [1,5,2,10,4,20,8,17,16,11,9,22,18,21,13,19,3,15,6,7,12,14] The only difference bewteen the sources is that in FFT1.lhs, lines 215 and 217 are present, while in FFT2.lhs, they are commented out. Note that these two lines reference the parameter, f. Also note that rader1 calls foo, so I am confused as to how that can produce different results, as test1 shows. FFT1.rader1 works for all n = 19, but fails for n = 23 (n has to be prime, however). Also, if I copy the offending code from FFT1.lhs to a separate file, then I get the results I expect, but this is a less than ideal solution. ghc-5.04.2 was installed with the Windows Installer from the website. If you play with the code, foo n should produce a permutation of the sequence [1..(n-1)] for all prime n (ie, foo n produces the permutation for a generator of the Galois field n). I appologize in advance if this is a bug on my part, but based on what I am seeing, I am getting results that should not happen. Thanks. -- Matthew Donadio ([EMAIL PROTECTED]) FFT2.lhs Description: haskellprogram Main2.hs Description: haskellprogram DFT.lhs Description: haskellprogram FFT1.lhs Description: haskellprogram Main1.hs Description: haskellprogram
RE: Bizarre Haskell Problem
I am having a bizarre Haskell problem that I am having difficulty debugging. I am not positive this is a compiler problem, but my results are not making any sense. I have attached a few source files which compiled with ghc-5.04.2 running under Win95. The files were compiled as: ghc -c DFT.lhs ghc -c FFT1.lhs ghc -c FFT2.lhs ghc -c Main1.hs ghc -c Mail2.hs ghc -o test1 Main1.o FFT1.o DFT.o ghc -o test2 Main2.o FFT2.o DFT.o Running test1 gives the following results (the last line is wrong): foo 19:[1,2,4,8,16,13,7,14,9,18,17,15,11,3,6,12,5,10] rader1 19: [1,2,4,8,16,13,7,14,9,18,17,15,11,3,6,12,5,10] foo 23:[1,5,2,10,4,20,8,17,16,11,9,22,18,21,13,19,3,15,6,7,12,14] rader1 23: [1,5,2,10,4,20,8,17,16,11,9,22,18,21,1,4,8,18,22,6,19,2] Running test2 gives the following results (these are the results I expect): foo 19:[1,2,4,8,16,13,7,14,9,18,17,15,11,3,6,12,5,10] rader1 19: [1,2,4,8,16,13,7,14,9,18,17,15,11,3,6,12,5,10] foo 23:[1,5,2,10,4,20,8,17,16,11,9,22,18,21,13,19,3,15,6,7,12,14] rader1 23: [1,5,2,10,4,20,8,17,16,11,9,22,18,21,13,19,3,15,6,7,12,14] Your problem is that rader1 has different types in FFT1 and FFT2: ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 5.04.2, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \/\/ /_/\/|_| Type :? for help. Loading package base ... linking ... done. Loading package haskell98 ... linking ... done. :Prelude :l FFT1 Skipping DFT ( DFT.lhs, DFT.o ) Skipping FFT1 ( FFT1.lhs, ./FFT1.o ) Ok, modules loaded: FFT1, DFT. Prelude FFT1 :t rader1 forall a b. (Integral a, GHC.Arr.Ix a, Num (Data.Complex.Complex b), RealFloat b) = GHC.Arr.Array a (Data.Complex.Complex b) - a - [a] Prelude FFT1 :t rader1 (gendata 23) 23 [Int] Prelude FFT1 :l FFT2 Skipping DFT ( DFT.lhs, DFT.o ) Skipping FFT2 ( FFT2.lhs, ./FFT2.o ) Ok, modules loaded: FFT2, DFT. Prelude FFT2 :t rader1 forall a t. (Integral a, GHC.Arr.Ix a) = t - a - [a] Prelude FFT2 :t rader1 (gendata 23) 23 forall a. (Integral a, GHC.Arr.Ix a) = [a] So in FFT2, defaulting will force the type variable a to Integer, whereas in FFT1 the type has already been forced to Int. I imagine that with Int you're getting some overflow, leading to the incorrect results. Moral of this story: type signatures can help to avoid unexpected behaviour... Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Bizarre Haskell Problem
Hi all, I am currently a having a bizarre Haskell problem, and was wondering if anyone had any suggestions. This is a snippet from a source file: foo n = [ a ^* i | i - [0..(n-2)] ] where i ^* j = (i ^ j) `mod` n a = generator n rader :: Array Int (Complex Double) - Int - Array Int (Complex Double) rader f n = foo a n -- DEBUG: should be f' where h = listArray (0,n-2) [ f!(a ^* (n-(1+n'))) | n' - [0..(n-2)] ] g = listArray (0,n-2) [ w (a ^* n') | n' - [0..(n-2)] ] f' = array (0,n-1) ((0, sum [ f!i | i - [0..(n-1)] ]) : [ (a ^* i, f!0 + sum [ h!j * g!((i-j)`mod`(n-1)) | j - [0..(n-2)] ]) | i - [0..(n-2)] ]) w i = cis (-2 * pi * fromIntegral i / fromIntegral n) i ^* j = (i ^ j) `mod` n a = generator n Under hugs and ghc, calling 'foo' and 'rader' with the proper arguments will give me different results under certain circumtances. In rader, n is the number of elements in the array. If n is 23, then everything is OK. If n = 23, then rader returns the wrong result. The bizarre thing is that if I comment out the definitions of h and f' in rader, then it returns the correct results. Hugs also give different reduction counts depending on whether h and f' are commented out or not. If I add any more definitions that reference f, then rader misbehaves. What is even more bizarre is that if I copy everything into a separate file, then it work for all n. Any suggestions or hints, other than just use a separate file? Separate files isn't really an option, because the above is simplified a bit, and the final version would have mutually recursive modules, which hugs can't handle. Thanks. -- Matthew Donadio ([EMAIL PROTECTED]) ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Bizarre Haskell Problem
My guess is that you are having an out-of-date .o of .hi file in your working directory. Clean it up and try again. All the best, Daan. - Original Message - From: Matthew Donadio [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, January 27, 2003 10:34 PM Subject: Bizarre Haskell Problem Hi all, I am currently a having a bizarre Haskell problem, and was wondering if anyone had any suggestions. This is a snippet from a source file: foo n = [ a ^* i | i - [0..(n-2)] ] where i ^* j = (i ^ j) `mod` n a = generator n rader :: Array Int (Complex Double) - Int - Array Int (Complex Double) rader f n = foo a n -- DEBUG: should be f' where h = listArray (0,n-2) [ f!(a ^* (n-(1+n'))) | n' - [0..(n-2)] ] g = listArray (0,n-2) [ w (a ^* n') | n' - [0..(n-2)] ] f' = array (0,n-1) ((0, sum [ f!i | i - [0..(n-1)] ]) : [ (a ^* i, f!0 + sum [ h!j * g!((i-j)`mod`(n-1)) | j - [0..(n-2)] ]) | i - [0..(n-2)] ]) w i = cis (-2 * pi * fromIntegral i / fromIntegral n) i ^* j = (i ^ j) `mod` n a = generator n Under hugs and ghc, calling 'foo' and 'rader' with the proper arguments will give me different results under certain circumtances. In rader, n is the number of elements in the array. If n is 23, then everything is OK. If n = 23, then rader returns the wrong result. The bizarre thing is that if I comment out the definitions of h and f' in rader, then it returns the correct results. Hugs also give different reduction counts depending on whether h and f' are commented out or not. If I add any more definitions that reference f, then rader misbehaves. What is even more bizarre is that if I copy everything into a separate file, then it work for all n. Any suggestions or hints, other than just use a separate file? Separate files isn't really an option, because the above is simplified a bit, and the final version would have mutually recursive modules, which hugs can't handle. Thanks. -- Matthew Donadio ([EMAIL PROTECTED]) ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
