2026/01/02

Newest at the top

2026-01-02 21:26:25 +0100 <monochrom> If you want something reused but don't want to bet, "let x = l !! bignumber in x + x" is the way. (Or "where".)
2026-01-02 21:25:41 +0100L29Ah(~L29Ah@wikipedia/L29Ah) ()
2026-01-02 21:24:29 +0100 <monochrom> So you lose both memory and time. Congratulations.
2026-01-02 21:24:17 +0100 <monochrom> If "l !! bignumber" is not shared but l is, then what happens is the worst of both worlds. First time, l is expanded and occupies 10^6 units of memory, and since it is to be shared, it won't be freed. Second time, you traverse that existing allocated memory from start to finish again.
2026-01-02 21:24:06 +0100mmohammadi9812(~mohammad@104.28.214.168) mmohammadi9812
2026-01-02 21:22:14 +0100 <monochrom> The common subexpression "l !! bignumber" is unlikely to be shared. This is at the whim of the code optimizer, but I bet unlikely. (But you should check empirically.)
2026-01-02 21:21:09 +0100 <monochrom> l is shared. That actually is worse news than you think.
2026-01-02 21:20:45 +0100 <monochrom> This is more nuisanced than one single boolean "is/not shared". (But you just need a multitude of booleans.)
2026-01-02 21:18:07 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds)
2026-01-02 21:17:03 +0100epitron(epi@user/epitron) epitron
2026-01-02 21:16:59 +0100wennefer0(~wennefer0@user/wennefer0) (Client Quit)
2026-01-02 21:16:16 +0100wennefer0(~wennefer0@user/wennefer0) wennefer0
2026-01-02 21:14:17 +0100 <Milan_Vanca> hmm
2026-01-02 21:13:21 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-01-02 21:10:00 +0100pavonia(~user@user/siracusa) siracusa
2026-01-02 21:09:22 +0100 <ncf> well you could extract the indices you need in one run
2026-01-02 21:07:39 +0100 <Milan_Vanca> If you look at page 5 of this document https://www.rfc-editor.org/rfc/rfc1321 There T[i] is value from list. I probably can't use `map` as function is always different. Or maybe I could zip it with index and then have case of to use correct function.
2026-01-02 21:07:30 +0100wennefer0(~wennefer0@user/wennefer0) (Client Quit)
2026-01-02 21:06:49 +0100img(~img@user/img) img
2026-01-02 21:05:47 +0100wennefer0(~wennefer0@user/wennefer0) wennefer0
2026-01-02 21:05:34 +0100img(~img@user/img) (Quit: ZNC 1.10.1 - https://znc.in)
2026-01-02 21:04:43 +0100 <Milan_Vanca> Oookey so I guess I should use Data.IntMap instead even tho every element of this map will be used in successive computations?
2026-01-02 21:03:55 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds)
2026-01-02 21:02:55 +0100 <tomsmeding> yep, l will be traversed 2 times from the start
2026-01-02 21:02:55 +0100 <geekosaur> there are ways to get the latter, I think, but that's not one of them
2026-01-02 21:02:35 +0100 <ncf> i'd be very surprised if GHC was smart enough to optimise the second traversal
2026-01-02 21:02:34 +0100 <geekosaur> the former
2026-01-02 20:59:38 +0100 <Milan_Vanca> I know l is shared and wont be created multiple times.. but to access element l !! bigIndex we need to traverse linken list. But will this list be traversed 2 times from start? Or will it traverse once till first Index and then just do one hop to second Index?
2026-01-02 20:59:22 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-01-02 20:58:21 +0100Inline(~User@cgn-195-14-221-74.nc.de) Inline
2026-01-02 20:57:47 +0100 <ncf> see https://en.wikibooks.org/wiki/Haskell/Graph_reduction
2026-01-02 20:57:07 +0100wennefer0(~wennefer0@user/wennefer0) (Client Quit)
2026-01-02 20:56:41 +0100 <ncf> l will be shared
2026-01-02 20:55:52 +0100wennefer0(~wennefer0@user/wennefer0) wennefer0
2026-01-02 20:53:19 +0100 <Milan_Vanca> Hello guyz. I know that !! for lists needs to traverse list to find index. But my question is let l = [0..] in (l !! 10^6 + 1) + ( l !! 10^6 + 2) + ... Will this traverse list multiple times? Or will reuse "iteration"?
2026-01-02 20:48:15 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds)
2026-01-02 20:47:39 +0100wennefer0(~wennefer0@user/wennefer0) (Client Quit)
2026-01-02 20:46:27 +0100wennefer0(~wennefer0@user/wennefer0) wennefer0
2026-01-02 20:46:03 +0100Milan_Vanca(~milan@user/Milan-Vanca:32634) Milan_Vanca
2026-01-02 20:43:34 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-01-02 20:42:55 +0100Inline(~User@cgn-195-14-221-74.nc.de) (Ping timeout: 240 seconds)
2026-01-02 20:37:38 +0100wennefer0(~wennefer0@user/wennefer0) (Client Quit)
2026-01-02 20:36:48 +0100Lord_of_Life_Lord_of_Life
2026-01-02 20:36:28 +0100wennefer0(~wennefer0@user/wennefer0) wennefer0
2026-01-02 20:36:15 +0100Lord_of_Life(~Lord@user/lord-of-life/x-2819915) (Ping timeout: 240 seconds)
2026-01-02 20:35:31 +0100Lord_of_Life_(~Lord@user/lord-of-life/x-2819915) Lord_of_Life
2026-01-02 20:32:40 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds)
2026-01-02 20:30:56 +0100rbdr(~rbdr@2a02:3100:23ad:aa00:e7fe:1cac:4507:3685) (Quit: rbdr)
2026-01-02 20:28:02 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-01-02 20:17:25 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds)