나는 악명 높은 H-99 problems의 도중에서 일하고 있는데, 나는 problem #6 (목록이 회문인지 아닌지 확인)을하고있다. 나는 대부분의 솔루션이 합리적으로 짧은 목록에서 합리적으로 잘 작동 함을 이해합니다. 이제 어떻게하스켈 (formidably long) palindrome check
let ll = [1..10000000] ++ [10000000, 10000000-1..1] ++ [7]
내가 (순진 아마도) 등을 테스트하기 위해 노력하는 매우 긴 목록은 예를 들면, 회문 경우 기능 테스트 작성합니다
isPalindrome [] = True
isPalindrome [_] = True
isPalindrome [x,y] = x==y
isPalindrome (x:xs) = isPalindrome [x,last xs] && (isPalindrome $ init xs)
I isPalindrome [x,last xs]
이 False
으로 평가되면 &&
의 비싼 오른 쪽은 평가되지 않는다고 가정합니다.
Mon Jun 30 18:33 2014 Time and Allocation Profiling Report (Final)
h99 +RTS -p -RTS
total time = 1.29 secs (1292 ticks @ 1000 us, 1 processor)
total alloc = 2,720,050,200 bytes (excludes profiling overheads)
COST CENTRE MODULE %time %alloc
main Main 95.6 100.0
isPalindrome Main 4.4 0.0
individual inherited
COST CENTRE MODULE no. entries %time %alloc %time %alloc
MAIN MAIN 43 0 0.0 0.0 100.0 100.0
CAF Main 85 0 0.0 0.0 100.0 100.0
main Main 86 1 95.6 100.0 100.0 100.0
isPalindrome Main 87 2 4.4 0.0 4.4 0.0
CAF GHC.Conc.Signal 84 0 0.0 0.0 0.0 0.0
CAF GHC.IO.Encoding 77 0 0.0 0.0 0.0 0.0
CAF GHC.IO.Encoding.Iconv 75 0 0.0 0.0 0.0 0.0
CAF GHC.IO.Handle.FD 68 0 0.0 0.0 0.0 0.0
CAF GHC.Show 63 0 0.0 0.0 0.0 0.0
있는 나는 문제가 전체 xs
을 계산하는 데 필요한 수 last xs
에 있음을 추론. 그렇다면 해결 방법이 있습니까? 또는 구현은 욕심이 입니까?
감사합니다.
하, 또! 하스켈 질문에 답해 주셔서 감사합니다. 실제로 'Data.Dequeue'가이 구현을위한 더 나은 데이터 구조 인 것 같습니다. –