2024/11/13

Newest at the top

2024-11-13 20:54:26 +0100 <tomsmeding> `containers` also does (Data.Map etc.)
2024-11-13 20:54:13 +0100 <tomsmeding> yes
2024-11-13 20:54:09 +0100 <haskellbridge> <thirdofmay18081814goya> oh wow ok the package annotates each function's time complexity
2024-11-13 20:54:03 +0100 <tomsmeding> as long as you're just reading into an existing immutable vector, almost anything sensible is fast
2024-11-13 20:53:46 +0100 <tomsmeding> Data.Vector has GHC rewrite rules (RULEs) that try to make creating vectors fast even if you use multiple functions after each other (e.g. cons, append, fromList), but for best results, try to create the whole thing in one go
2024-11-13 20:53:46 +0100mantraofpie(~mantraofp@user/mantraofpie) (Ping timeout: 260 seconds)
2024-11-13 20:52:52 +0100 <tomsmeding> cons creates a new vector
2024-11-13 20:52:51 +0100hellwolf(~user@0e2f-3a3b-aecf-adb3-0f00-4d40-07d0-2001.sta.estpak.ee) hellwolf
2024-11-13 20:52:47 +0100 <tomsmeding> tail and init are read-only
2024-11-13 20:52:36 +0100 <haskellbridge> <thirdofmay18081814goya> wait sorry I'm not fully understanding, what distinguishes tail/init vs. tail/cons?
2024-11-13 20:52:31 +0100mantraofpie_(~mantraofp@user/mantraofpie) mantraofpie
2024-11-13 20:51:18 +0100 <tomsmeding> (so tail/init etc. are actually quite fine, they are O(1) and just produce views on the underlying data)
2024-11-13 20:50:19 +0100weary-traveler(~user@user/user363627) (Remote host closed the connection)
2024-11-13 20:49:51 +0100 <tomsmeding> read-only you can do essentially whatever you wish; for producing vectors, you should try to produce the whole thing in one go
2024-11-13 20:49:26 +0100 <tomsmeding> what you should be wary of is tail/cons
2024-11-13 20:49:17 +0100 <tomsmeding> no Foldable/Traversable are perfectly fine
2024-11-13 20:49:04 +0100 <haskellbridge> <thirdofmay18081814goya> i'll have a look i was weary of just focusing on the existence of the "Foldable" instance by fear of the possibility it would just throw out the performance benefits
2024-11-13 20:48:24 +0100 <tomsmeding> but really, just glance through https://hackage.haskell.org/package/vector-0.13.2.0/docs/Data-Vector.html
2024-11-13 20:47:54 +0100 <tomsmeding> and you can unfoldrN (unfoldr with a known target size)
2024-11-13 20:47:49 +0100 <haskellbridge> <thirdofmay18081814goya> tomsmeding: anything really i usually use my usernames as memory palaces
2024-11-13 20:47:31 +0100JuanDaugherty(~juan@user/JuanDaugherty) (Quit: JuanDaugherty)
2024-11-13 20:47:30 +0100 <haskellbridge> <thirdofmay18081814goya> vs. the imperative representation of arrays as things you "for" loop over
2024-11-13 20:47:25 +0100 <tomsmeding> but you can foldr
2024-11-13 20:47:21 +0100 <tomsmeding> you should not treat a Vector as a linked list
2024-11-13 20:47:07 +0100 <haskellbridge> <thirdofmay18081814goya> i.e. the general ability to pattern match
2024-11-13 20:47:00 +0100 <haskellbridge> <thirdofmay18081814goya> uh well I'm mostly reasoning very loosely about cata/ana, wrt List the significant part in both cases is a pattern match on "cons" into some other datatype (cata very loosely) or a pattern match on some other type onto "List" (ana very loosely)
2024-11-13 20:45:50 +0100 <tomsmeding> thirdofmay18081814goya: how should we properly mention you, because it's bridged (and not plumbed) your mxid is not a nick here, so we don't have autocomplete
2024-11-13 20:45:05 +0100abrar(~abrar@pool-72-78-199-167.phlapa.fios.verizon.net)
2024-11-13 20:45:05 +0100 <EvanR> had to review the log carefully to see who "goya" is xD
2024-11-13 20:44:55 +0100 <haskellbridge> <zwro> tomsmeding: you're absolutely correct. my examples were bad. i'm sure i had some kind of problem with driving Functor in the past but can't remember the exact case. maybe later it'll come to me
2024-11-13 20:44:40 +0100 <tomsmeding> goya: if you point to the precise "ana/cata/hylo" methods that you mean (there are various packages defining them in various ways iirc), then we could see how compatible the type signatures would be
2024-11-13 20:44:25 +0100 <EvanR> you can still treat it like a representable functor
2024-11-13 20:43:43 +0100 <tomsmeding> there are no recursion schemes for the thing because, well, it's not a tree
2024-11-13 20:43:35 +0100peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich
2024-11-13 20:43:28 +0100 <tomsmeding> it has a Foldable instance, and there are various methods
2024-11-13 20:43:11 +0100 <EvanR> vector package, Data.Vector
2024-11-13 20:43:00 +0100 <haskellbridge> <thirdofmay18081814goya> what module for said "Vector"?
2024-11-13 20:42:53 +0100abrar(~abrar@pool-72-78-199-167.phlapa.fios.verizon.net) (Ping timeout: 245 seconds)
2024-11-13 20:42:42 +0100 <EvanR> and has a bunch of snazzy rewrite rules for fusion
2024-11-13 20:42:14 +0100 <EvanR> but is implemented behind the scenes in a compact way
2024-11-13 20:42:03 +0100 <tomsmeding> goya: how are they defined for Vector?
2024-11-13 20:41:55 +0100 <EvanR> has a lot of instances like List does
2024-11-13 20:41:46 +0100 <EvanR> Vector is pretty good
2024-11-13 20:40:51 +0100 <haskellbridge> <thirdofmay18081814goya> can I still think in terms of ana/cata/hylo or will this destroy the performance benefits?
2024-11-13 20:40:38 +0100 <haskellbridge> <thirdofmay18081814goya> long time user of "List", now need to use arrays from performance-critical usecase (processing logs, text files of more than 3 million lines)
2024-11-13 20:40:14 +0100alexherbo2(~alexherbo@2a02-8440-3117-f07c-987b-fc29-77ee-addd.rev.sfr.net) alexherbo2
2024-11-13 20:37:13 +0100ash3en(~Thunderbi@ip1f10cbd6.dynamic.kabel-deutschland.de) (Client Quit)
2024-11-13 20:34:30 +0100 <tomsmeding> (one could of course design the _classes_ differently, but that's a separate topic)
2024-11-13 20:34:08 +0100 <tomsmeding> (my point was: I agree with your feelings, but the types imply this: "feels weird" =/=> "there are other choices for GHC's deriving mechanism")
2024-11-13 20:33:35 +0100 <tomsmeding> sure