User talk:WillNess: Difference between revisions

Content added Content deleted
(→‎Space complexity improvement -- Hamming numbers: Congratulations on such a concise expression but...)
Line 66: Line 66:


::: Interesting stuff, thanks. Of course I always expect the more abstract source code to be compiled into as efficient low-level code as possible; that was The High Premise of Equational Reasoning as I understood it. All this toiling with the minutiae of coding is off-putting for me. I'd rather prefer <code>(sum *** concat) . unzip $ [.....]</code> instead. :) :) -- [[User:WillNess|WillNess]] ([[User talk:WillNess|talk]]) 09:03, 21 August 2016 (UTC)
::: Interesting stuff, thanks. Of course I always expect the more abstract source code to be compiled into as efficient low-level code as possible; that was The High Premise of Equational Reasoning as I understood it. All this toiling with the minutiae of coding is off-putting for me. I'd rather prefer <code>(sum *** concat) . unzip $ [.....]</code> instead. :) :) -- [[User:WillNess|WillNess]] ([[User talk:WillNess|talk]]) 09:03, 21 August 2016 (UTC)

:::: That's a beautiful expression of the code, but it has a horrible space leak such that it's "out of memory" for anything much above 10 billion and takes about 80% of the time on garbage collection; I think the problem is that the generated zip list is entirely unevaluated (including the "add to list" predicate check) until used by the "sum" and "sortBy" functions - a problem that the "foldl'" version didn't have as it was forced to be strict. I'm afraid that while the THPoER highly abstract form can sometimes reduce complex code into something simple such that it runs faster, in this case, the abstract code comes at an extremely high cost, due to it practically being expressed as non-strict lists with the construction of such lists taking many extra cycles in the innermost loop. There are also the practical matters of memory use and garbage collection... Sometimes we need to look at code from a low level perspective to see what it is really doing; I'm afraid that in this case the non-strictness of Haskell has bitten you on the a... ;) --[[User:GordonBGood|GordonBGood]] ([[User talk:GordonBGood|talk]]) 03:56, 22 August 2016 (UTC)