[GHC] #14187: Transpose hangs on infinite by finite lists
#14187: Transpose hangs on infinite by finite lists -------------------------------------+------------------------------------- Reporter: utikeev | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: transpose | Operating System: Windows Architecture: x86_64 | Type of failure: Runtime (amd64) | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I found out that this code {{{#!hs take 5 $ map (take 3) (transpose (repeat [0..1])) }}} isn't equivalent to this one {{{#!hs take 5 $ map (take 3) [[0,0..], [1,1..]] }}} The second piece of code gives expectable output of {{{[[0,0,0],[1,1,1]]}}}, while first one just hangs with outpit {{{[[0,0,0],[1,1,1],}}} also probably screwing up some descriptors after interruption with Ctrl+C (as in 8.2.1, didn't have such problem in 8.0.2. I attach the screenshot of my cmd after interruption and pressing Up and Down buttons randomly for a few times. The history seems to be broken). In my homework I had to make a function zipN, which is actually zipWith but for more than two lists. The solution which dealt with stuck was to write my own transpose and apply {{{takeWhile (not . null)}}} to the remaining part of transposed matrix. P.S.: {{{#!hs [[0,0..],[1,1..]] == transpose (repeat [0..1]) }}} also hangs ghci. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14187 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#14187: Transpose hangs on infinite by finite lists -------------------------------------+------------------------------------- Reporter: utikeev | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: transpose Operating System: Windows | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by utikeev): * Attachment "Screenshot_5.png" added. Cmd with broken history after hanging -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14187 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#14187: Transpose hangs on infinite by finite lists -------------------------------------+------------------------------------- Reporter: utikeev | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: transpose Operating System: Windows | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by utikeev: Old description:
I found out that this code
{{{#!hs take 5 $ map (take 3) (transpose (repeat [0..1])) }}}
isn't equivalent to this one
{{{#!hs take 5 $ map (take 3) [[0,0..], [1,1..]] }}}
The second piece of code gives expectable output of {{{[[0,0,0],[1,1,1]]}}}, while first one just hangs with outpit {{{[[0,0,0],[1,1,1],}}} also probably screwing up some descriptors after interruption with Ctrl+C (as in 8.2.1, didn't have such problem in 8.0.2. I attach the screenshot of my cmd after interruption and pressing Up and Down buttons randomly for a few times. The history seems to be broken).
In my homework I had to make a function zipN, which is actually zipWith but for more than two lists. The solution which dealt with stuck was to write my own transpose and apply {{{takeWhile (not . null)}}} to the remaining part of transposed matrix.
P.S.: {{{#!hs [[0,0..],[1,1..]] == transpose (repeat [0..1]) }}} also hangs ghci.
New description: I found out that this code {{{#!hs take 5 $ map (take 3) (transpose (repeat [0..1])) }}} isn't equivalent to this one {{{#!hs take 5 $ map (take 3) [[0,0..], [1,1..]] }}} The second piece of code gives expectable output of {{{[[0,0,0],[1,1,1]]}}}, while first one just hangs with output {{{[[0,0,0],[1,1,1],}}} also probably screwing up some descriptors after interruption with Ctrl+C (as in 8.2.1, didn't have such problem in 8.0.2. I attach the screenshot of my cmd after interruption and pressing Up and Down buttons randomly for a few times. The history seems to be broken). In my homework I had to make a function zipN, which is actually zipWith but for more than two lists. The solution which dealt with stuck was to write my own transpose and apply {{{takeWhile (not . null)}}} to the remaining part of transposed matrix. P.S.: {{{#!hs [[0,0..],[1,1..]] == transpose (repeat [0..1]) }}} also hangs ghci. -- -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14187#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#14187: Transpose hangs on infinite by finite lists -------------------------------------+------------------------------------- Reporter: utikeev | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: invalid | Keywords: transpose Operating System: Windows | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by nomeata): * status: new => closed * resolution: => invalid Comment: Thanks for your report. This is expected behavior. Note that the documentation says
The transpose function transposes the rows and columns of its argument. For example,
transpose [[1,2,3],[4,5,6]] == [[1,4],[2,5],[3,6]]
If some of the rows are shorter than the following rows, their elements are skipped:
transpose [[10,11],[20],[],[30,31,32]] == [[10,20,30],[11,31],[32]]
Note that `repeat [0,1] = [[0,1],[0,1],[0,1],[0,1],[0,1],…`. So if you look at the third element of `transpose (repeat [0,1])` then it has to skip the first `[0,1]` in the list of lists, as it has no third element. Then it skips the second, for the same reason, and goes on like that for ever. (You might wonder why it doesn’t detect that, because you use `repeat`, that _no_ element in the list has a third element – but that kind of reasoning is beyond what you can expect from a compiler, unfortunately.) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14187#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#14187: Transpose hangs on infinite by finite lists -------------------------------------+------------------------------------- Reporter: utikeev | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: invalid | Keywords: transpose Operating System: Windows | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #14150 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #14150 Comment: As for why the console bugs out after you type Ctrl+C—I believe that is due to #14150. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14187#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#14187: Transpose hangs on infinite by finite lists -------------------------------------+------------------------------------- Reporter: utikeev | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: invalid | Keywords: transpose Operating System: Windows | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #14150 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by utikeev): Replying to [comment:2 nomeata]:
Thanks for your report. ...
Thanks a lot for clarifying that! It's true that I expected the behaviour which you described in brackets in the end of your reply, but now when I thought a bit about it, it seems reasonably fair that it doesn't work the way I want. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14187#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
participants (1)
-
GHC