StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
6122830
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
2
CommunityOwnedDate
CreationDate
2011-05-25T10:15:57.343
FavoriteCount
0
LastActivityDate
2011-05-25T10:21:40.290
LastEditDate
2011-05-25T10:21:40.290
LastEditorUserId
370541
OwnerUserId
370541
ParentId
6121256
PostTypeId
2
Score
19
ViewCount
0
LastEditorDisplayName
text
Body
First of all, I don't think you want to be working with lists. A lot of your algorithms rely upon calculating the length, which is bad. You may want to consider the <a href="http://hackage.haskell.org/package/vector">vector</a> package, which will give you O(1) length compared to O(n) for a list. Vectors are also much more memory efficient, particularly if you can use Unboxed or Storable variants. That being said, you really need to consider traversals and usage patterns in your code. Haskell's lists are very efficient if they can be generated on demand and consumed once. This means that you shouldn't hold on to references to a list. Something like this: <pre><code>average xs = sum xs / length xs </code></pre> requires that the entire list be retained in memory (by either <code>sum</code> or <code>length</code>) until both traversals are completed. If you can do your list traversal in one step, it'll be much more efficient. Of course, you may need to retain the list anyway, such as to check if all the elements are equal, and if they aren't, do something else with the data. In this case, with lists of any size you're probably better off with a more compact data structure (e.g. vector). Now that this is out of they way, here's a look at each of these functions. Where I show core, it was generated with <code>ghc-7.0.3 -O -ddump-simpl</code>. Also, don't bother judging Haskell code performance when compiled with -O0. Compile it with the flags you would actually use for production code, typically at least -O and maybe other options too. Solution 0 <pre><code>allTheSame :: (Eq a) => [a] -> Bool allTheSame xs = and $ map (== head xs) (tail xs) </code></pre> GHC produces this Core: <pre><code>Test.allTheSame :: forall a_abG. GHC.Classes.Eq a_abG => [a_abG] -> GHC.Bool.Bool [GblId, Arity=2, Str=DmdType LS, Unf=Unf{Src=<vanilla>, TopLvl=True, Arity=2, Value=True, ConLike=True, Cheap=True, Expandable=True, Guidance=IF_ARGS [3 3] 16 0}] Test.allTheSame = \ (@ a_awM) ($dEq_awN :: GHC.Classes.Eq a_awM) (xs_abH :: [a_awM]) -> case xs_abH of _ { [] -> GHC.List.tail1 `cast` (CoUnsafe (forall a1_axH. [a1_axH]) GHC.Bool.Bool :: (forall a1_axH. [a1_axH]) ~ GHC.Bool.Bool); : ds1_axJ xs1_axK -> letrec { go_sDv [Occ=LoopBreaker] :: [a_awM] -> GHC.Bool.Bool [LclId, Arity=1, Str=DmdType S] go_sDv = \ (ds_azk :: [a_awM]) -> case ds_azk of _ { [] -> GHC.Bool.True; : y_azp ys_azq -> case GHC.Classes.== @ a_awM $dEq_awN y_azp ds1_axJ of _ { GHC.Bool.False -> GHC.Bool.False; GHC.Bool.True -> go_sDv ys_azq } }; } in go_sDv xs1_axK } </code></pre> This looks pretty good, actually. It will produce an error with an empty list, but that's easily fixed. This is the <code>case xs_abH of _ { [] -></code>. After this GHC performed a worker/wrapper transformation, the recursive worker function is the <code>letrec { go_sDv</code> binding. The worker examines its argument. If <code>[]</code>, it's reached the end of the list and returns True. Otherwise it compares the head of the remaining to the first element and either returns False or checks the rest of the list. Three other features. <ol> <li>The <code>map</code> was entirely fused away and doesn't allocate a temporary list.</li> <li>Near the top of the definition notice the <code>Cheap=True</code> statement. This means GHC considers the function "cheap", and thus a candidate for inlining. At a call site, if a concrete argument type can be determined, GHC will probably inline <code>allTheSame</code> and produce a very tight inner loop, completely bypassing the <code>Eq</code> dictionary lookup.</li> <li>The worker function is tail-recursive.</li> </ol> Verdict: Very strong contender. Solution 1 <pre><code>allTheSame' :: (Eq a) => [a] -> Bool allTheSame' xs = (length xs) == (length $ takeWhile (== head xs) xs) </code></pre> Even without looking at core I know this won't be as good. The list is traversed more than once, first by <code>length xs</code> then by <code>length $ takeWhile</code>. Not only do you have the extra overhead of multiple traversals, it means that the list must be retained in memory after the first traversal and can't be GC'd. For a big list, this is a serious problem. <pre><code>Test.allTheSame' :: forall a_abF. GHC.Classes.Eq a_abF => [a_abF] -> GHC.Bool.Bool [GblId, Arity=2, Str=DmdType LS, Unf=Unf{Src=<vanilla>, TopLvl=True, Arity=2, Value=True, ConLike=True, Cheap=True, Expandable=True, Guidance=IF_ARGS [3 3] 20 0}] Test.allTheSame' = \ (@ a_awF) ($dEq_awG :: GHC.Classes.Eq a_awF) (xs_abI :: [a_awF]) -> case GHC.List.$wlen @ a_awF xs_abI 0 of ww_aC6 { __DEFAULT -> case GHC.List.$wlen @ a_awF (GHC.List.takeWhile @ a_awF (let { ds_sDq :: a_awF [LclId, Str=DmdType] ds_sDq = case xs_abI of _ { [] -> GHC.List.badHead @ a_awF; : x_axk ds1_axl -> x_axk } } in \ (ds1_dxa :: a_awF) -> GHC.Classes.== @ a_awF $dEq_awG ds1_dxa ds_sDq) xs_abI) 0 of ww1_XCn { __DEFAULT -> GHC.Prim.==# ww_aC6 ww1_XCn } } </code></pre> Looking at the core doesn't tell much beyond that. However, note these lines: <pre><code>case GHC.List.$wlen @ a_awF xs_abI 0 of ww_aC6 { __DEFAULT -> case GHC.List.$wlen </code></pre> This is where the list traversals happen. The first gets the length of the outer list and binds it to <code>ww_aC6</code>. The second gets the length of the inner list, but the binding doesn't happen until near the bottom, at <pre><code>of ww1_XCn { __DEFAULT -> GHC.Prim.==# ww_aC6 ww1_XCn </code></pre> The lengths (both <code>Int</code>s) can be unboxed and compared by a primop, but that's a small consolation after the overhead that's been introduced. Verdict: Not good. Solution 2 <pre><code>allTheSame'' :: (Eq a) => [a] -> Bool allTheSame'' xs | n == 0 = False | n == 1 = True | n == 2 = xs !! 0 == xs !! 1 | otherwise = (xs !! 0 == xs !! 1) && (allTheSame'' $ snd $ splitAt 2 xs) where n = length xs </code></pre> This has the same problem as solution 1. The list is traversed multiple times, and it can't be GC'd. It's worse here though, because now the length is calculated for each sub-list. I'd expect this to have the worst performance of all on lists of any significant size. Also, why are you special-casing lists of 1 and 2 elements when you're expecting the list to be big? Verdict: Don't even think about it. Solution 3 <pre><code>allTheSame''' :: (Eq a) => [a] -> Bool allTheSame''' xs | n == 0 = False | n == 1 = True | n == 2 = xs !! 0 == xs !! 1 | n == 3 = xs !! 0 == xs !! 1 && xs !! 1 == xs !! 2 | otherwise = allTheSame''' (fst split) && allTheSame''' (snd split) where n = length xs split = splitAt (n `div` 2) xs </code></pre> This has the same problem as Solution 2. Namely, the list is traversed multiple times by <code>length</code>. I'm not certain a divide-and-conquer approach is a good choice for this problem, it could end up taking longer than a simple scan. It would depend on the data though, and be worth testing. Verdict: Maybe, if you used a different data structure. Solution 4 <pre><code>allTheSame'''' :: (Eq a) => [a] -> Bool allTheSame'''' xs = all (== head xs) (tail xs) </code></pre> This was basically my first thought. Let's check the core again. <pre><code>Test.allTheSame'''' :: forall a_abC. GHC.Classes.Eq a_abC => [a_abC] -> GHC.Bool.Bool [GblId, Arity=2, Str=DmdType LS, Unf=Unf{Src=<vanilla>, TopLvl=True, Arity=2, Value=True, ConLike=True, Cheap=True, Expandable=True, Guidance=IF_ARGS [3 3] 10 0}] Test.allTheSame'''' = \ (@ a_am5) ($dEq_am6 :: GHC.Classes.Eq a_am5) (xs_alK :: [a_am5]) -> case xs_alK of _ { [] -> GHC.List.tail1 `cast` (CoUnsafe (forall a1_axH. [a1_axH]) GHC.Bool.Bool :: (forall a1_axH. [a1_axH]) ~ GHC.Bool.Bool); : ds1_axJ xs1_axK -> GHC.List.all @ a_am5 (\ (ds_dwU :: a_am5) -> GHC.Classes.== @ a_am5 $dEq_am6 ds_dwU ds1_axJ) xs1_axK } </code></pre> Ok, not too bad. Like solution 1, this will error on empty lists. The list traversal is hidden in <code>GHC.List.all</code>, but it will probably be expanded to good code at a call site. Verdict: Another strong contender. So between all of these, with lists I'd expect that Solutions 0 and 4 are the only ones worth using, and they are pretty much the same. I might consider Option 3 in some cases. Edit: in both cases, the errors on empty lists can be simply fixed as in @augustss's answer. The next step would be to do some time profiling with <a href="http://hackage.haskell.org/package/criterion">criterion</a>.
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. POefficiently checking that all the elements of a (big) list are the same
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. USJohn L
UserOwnerUserId
1. USJohn L
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. This table or related slice is empty.
PostsParentIdCreationDate
1. This table or related slice is empty.
VotesPostIdCreationDate
1. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
2. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
3. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
CommentsPostId
1. COwow! impressive answer. I must admit that I don't understand anything looking at core code: that's far too advanced for me at the moment. However your explanations are very useful, and they gave me insight on many aspects and errors in my code. Thanks!
 singulars
 PostPostId
 PO
 UserUserId
 USMarcoS

Querying!

Guidance

A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.