Home freenode/#haskell: Logs Calendar

Logs: freenode/#haskell

←Prev  Next→
Page 1 .. 1070 1071 1072 1073 1074 1075 1076 1077 1078 1079 1080 .. 5022
— 502,152 events total
2020-11-05 08:14:55 × danvet_ quits (~danvet@2a02:168:57f4:0:5f80:650d:c6e6:3453) (Remote host closed the connection)
2020-11-05 08:15:13 × kav quits (~kari@dsl-hkibng42-56733f-225.dhcp.inet.fi) (Ping timeout: 246 seconds)
2020-11-05 08:15:51 × hololeap quits (~hololeap@unaffiliated/hololeap) (Ping timeout: 265 seconds)
2020-11-05 08:16:12 → cfricke joins (~cfricke@unaffiliated/cfricke)
2020-11-05 08:16:38 <scasc> yushyin: Thanks, I remembered having seen base versions tabulated somewhere.
2020-11-05 08:16:58 <scasc> That could be augmented with release dates for the GHC versions :-)
2020-11-05 08:17:01 × dbmikus_ quits (~dbmikus@cpe-76-167-86-219.natsow.res.rr.com) (Ping timeout: 264 seconds)
2020-11-05 08:17:29 → Tuplanolla joins (~Tuplanoll@91-159-68-239.elisa-laajakaista.fi)
2020-11-05 08:18:24 × Sgeo quits (~Sgeo@ool-18b982ad.dyn.optonline.net) (Read error: Connection reset by peer)
2020-11-05 08:18:31 × yinfeng quits (~yinfeng@2001:250:5002:8100::3:bd7b) (Ping timeout: 244 seconds)
2020-11-05 08:19:39 → britva joins (~britva@31-10-157-156.cgn.dynamic.upc.ch)
2020-11-05 08:20:34 → yinfeng joins (~yinfeng@122.96.106.57)
2020-11-05 08:20:45 → rotty joins (rotty@ghost.xx.vu)
2020-11-05 08:21:24 × nbloomf_ quits (~nbloomf@2600:1700:ad14:3020:b093:9754:189c:f0eb) (Quit: My MacBook has gone to sleep. ZZZzzz…)
2020-11-05 08:22:02 → gehmehgeh joins (~ircuser1@gateway/tor-sasl/gehmehgeh)
2020-11-05 08:22:02 <[exa]> dminuoso: they are great for user-specified grammar parts where you don't want a full compiler in your program
2020-11-05 08:22:05 × christo quits (~chris@81.96.113.213) (Remote host closed the connection)
2020-11-05 08:22:54 → kav joins (~kari@dsl-hkibng42-56733f-225.dhcp.inet.fi)
2020-11-05 08:23:59 <[exa]> dminuoso: like, I'd really love a library now with a more transparent interface than regex-base
2020-11-05 08:24:19 <dminuoso> [exa]: pcre-heavy has a good interface
2020-11-05 08:24:31 × hidedagger quits (~nate@125.161.131.218) (Quit: WeeChat 2.9)
2020-11-05 08:24:45 <[exa]> will have a look, thanks
2020-11-05 08:25:21 <[exa]> the point is that regex-base somehow seems to mainly support the mode of use that sounds wrong to me (eg writing a regex to your program to check a mail)
2020-11-05 08:26:25 → jess joins (jess@freenode/staff/jess)
2020-11-05 08:26:52 <[exa]> ok pcre-heavy and pcre-light are cool
2020-11-05 08:27:05 <[exa]> is there something similar without external deps? I'm now on regex-tdfa
2020-11-05 08:28:56 → mimi_vx joins (~mimi@tulipan.habr.nat.praha12.net)
2020-11-05 08:29:34 <dminuoso> [exa]: Mmm, regex-applicative perhaps
2020-11-05 08:29:41 <dminuoso> (Which is also a library Im quite fond of)
2020-11-05 08:30:01 <[exa]> ok sounds good
2020-11-05 08:30:05 <dminuoso> It's a cross between parser combinators and regular expressions, but it gets away with pure haskell instead of QQs
2020-11-05 08:30:15 <[exa]> looks good
2020-11-05 08:31:01 → fraktor joins (~walt@129.93.191.18)
2020-11-05 08:31:12 <[exa]> palpatine voice: goooooood
2020-11-05 08:31:16 <lortabac> my personal problem with common regex implementations is the stringy syntax
2020-11-05 08:31:22 <fraktor> I've got a question that's kind of a general algorithms question, but I'm planning on attempting to implement it in Haskell. Is here a good place to ask?
2020-11-05 08:31:32 <lortabac> I wasn't aware of regex-applicative, it looks good
2020-11-05 08:31:40 <[exa]> fraktor: quite possibly yes, you'll get a decent redirect if not :]
2020-11-05 08:31:48 <fraktor> Fair enough.
2020-11-05 08:31:53 → borne joins (~fritjof@200116b8643b36005d0cb1433c5d4cbb.dip.versatel-1u1.de)
2020-11-05 08:32:28 <[exa]> ok that sounds like it.. like, regex strings and QQs have imho no place in good code when you can write it right (and more extensibly) using standard haskell
2020-11-05 08:32:29 → kritzefitz joins (~kritzefit@fw-front.credativ.com)
2020-11-05 08:32:47 <fraktor> I've got a problem that is kind of like 1d bin packing, but different. Basically, I have several objects, and bins of several sizes. I can have as many of each kind of bin as I want, but I need to minimize the total amount of space left over in each bin.
2020-11-05 08:33:23 → hidedagger joins (~nate@125.161.131.218)
2020-11-05 08:34:35 <[exa]> fraktor: the objects have 1D size?
2020-11-05 08:34:43 <fraktor> For the purpose of this problem yes.
2020-11-05 08:35:31 <fraktor> Actually I'll just share the practical application of this: I need to cut several lengths of 2x4, and I can buy boards in pre-determined lengths. I want to minimize waste.
2020-11-05 08:35:33 <[exa]> so the input is say objectSizes=[1,2,3,4,10] and you have binSizes=[8,11] and try to minimize the amount of space in used bins that is unfilled, right?
2020-11-05 08:35:48 <fraktor> Exactly. But there may be multiple objects of the same size.
2020-11-05 08:35:49 → christo joins (~chris@81.96.113.213)
2020-11-05 08:36:06 × scasc quits (~szabi@213142096120.public.telering.at) (Quit: Leaving)
2020-11-05 08:36:23 <[exa]> this sounds like a knapsack but hopefully it's not that bad. :]
2020-11-05 08:36:43 <lortabac> fraktor: do you also want to minimize the number of bins you use? (by putting more than 1 object in a bin)
2020-11-05 08:38:26 <[exa]> imho not necessariy (unless shorter boards are proportionally more expensive than longer boards)
2020-11-05 08:38:33 × heatsink quits (~heatsink@107-136-5-69.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection)
2020-11-05 08:38:47 <fraktor> All other things being equal, yeah, but I'd rather reduce waste than have fewer boards.
2020-11-05 08:39:02 <fraktor> And it's certainly not critical.
2020-11-05 08:39:10 → heatsink joins (~heatsink@107-136-5-69.lightspeed.sntcca.sbcglobal.net)
2020-11-05 08:39:54 <lortabac> if you can afford 1 object for each bin, I'd say you don't need any algorithm at all, you just choose the first bin your object fits in
2020-11-05 08:40:50 × dmiles quits (dmiles@c-73-67-179-188.hsd1.wa.comcast.net) (Read error: Connection reset by peer)
2020-11-05 08:40:54 × britva quits (~britva@31-10-157-156.cgn.dynamic.upc.ch) (Quit: This computer has gone to sleep)
2020-11-05 08:40:56 → merijn joins (~merijn@83-160-49-249.ip.xs4all.nl)
2020-11-05 08:41:33 <fraktor> What if I have objects [1, 2, 2], and I have bins [1, 3]? Then I would end up with [([1], 1), ([2], 3), ([2], 3)], even though [([1, 2], 3), ([2], 3)] is a more efficient packing.
2020-11-05 08:41:51 <fraktor> The first packing has 2 units of waste, while the second packing only has 1.
2020-11-05 08:42:31 <lortabac> ok I understand now
2020-11-05 08:42:48 → dmiles joins (dmiles@c-73-67-179-188.hsd1.wa.comcast.net)
2020-11-05 08:42:57 <[exa]> lortabac: that would generate a lot of waste
2020-11-05 08:43:26 <[exa]> fraktor: how many objects/bins do you expect?
2020-11-05 08:43:30 × heatsink quits (~heatsink@107-136-5-69.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 256 seconds)
2020-11-05 08:43:44 <fraktor> Bins, let's say 4, and objects, I'd say about 20.
2020-11-05 08:43:59 <fraktor> But I'd like something that scales efficiently if at all possible.
2020-11-05 08:44:06 → britva joins (~britva@2a02:aa13:7240:2980:9117:32f5:aa09:6904)
2020-11-05 08:44:08 × Lord_of_Life quits (~Lord@46.217.217.162) (Changing host)
2020-11-05 08:44:08 → Lord_of_Life joins (~Lord@unaffiliated/lord-of-life/x-0885362)
2020-11-05 08:44:17 <[exa]> well for now just enjoy the computers and go brute force :D
2020-11-05 08:44:47 <lortabac> :)
2020-11-05 08:45:21 <fraktor> That's still relatively large, as far as I can tell. Like, I would have to check every ordering of the objects, and then every possible grouping for that ordering, right?
2020-11-05 08:46:32 → watt976 joins (~watt976@124.123.107.59)
2020-11-05 08:47:22 <[exa]> I'm starting to suspect there'd be a dynamic programming solution
2020-11-05 08:47:51 <lortabac> you can probably reframe the problem to be solvable with linear programming, by giving a sufficiently big (finite) number of bins
2020-11-05 08:48:34 <fraktor> I mean, the largest number of bins would be the number of objects, so I have a hard upper bound. But I'm not that familiar with linear programming.
2020-11-05 08:48:50 <[exa]> that's going to just transfer the guesswork to the linear solver :]
2020-11-05 08:48:53 <fraktor> And this definitely does seem like the kind of thing that would have a dynamic programming solution, but I'm not sure I could figure it out when I'm this tired lol.
2020-11-05 08:49:00 → temporary1233 joins (~szabi@213142096120.public.telering.at)
2020-11-05 08:50:01 <[exa]> ok technically, lets give it a bit of determinism
2020-11-05 08:50:14 × britva quits (~britva@2a02:aa13:7240:2980:9117:32f5:aa09:6904) (Quit: This computer has gone to sleep)
2020-11-05 08:50:34 → britva joins (~britva@2a02:aa13:7240:2980:9117:32f5:aa09:6904)
2020-11-05 08:51:12 <[exa]> 1] it doesn't matter in which order you choose the boards and cut out the parts you want, so you can work the algorithm as iterative nondeterministic "I cut out a first piece and might have either this board left, or that board left"
2020-11-05 08:51:50 × watt976 quits (~watt976@124.123.107.59) (Remote host closed the connection)
2020-11-05 08:52:01 <fraktor> Are you saying that cutting [2, 1] out of a board is functionally equivalent to cutting out [1, 2]? I'd agree.
2020-11-05 08:52:19 → __monty__ joins (~toonn@unaffiliated/toonn)
2020-11-05 08:52:24 → watt332 joins (~watt332@124.123.107.59)
2020-11-05 08:52:31 <[exa]> then heuristic, 2] cut out the pieces that are most unwieldy first
2020-11-05 08:52:44 <[exa]> so that you don't have to generate a lots of waste towards the end of the search
2020-11-05 08:52:44 → PlasmaSt` joins (~mattplasm@45.83.89.28)
2020-11-05 08:52:55 <[exa]> 3] branch bound and hope
2020-11-05 08:54:06 × hidedagger quits (~nate@125.161.131.218) (Quit: WeeChat 2.9)
2020-11-05 08:54:28 → mmohammadi9812 joins (~mmohammad@5.113.30.246)
2020-11-05 08:54:34 × PlasmaStrike quits (~mattplasm@45.83.89.28) (Ping timeout: 260 seconds)
2020-11-05 08:54:36 × mmohammadi9812 quits (~mmohammad@5.113.30.246) (Client Quit)
←Prev  Next→
Page 1 .. 1070 1071 1072 1073 1074 1075 1076 1077 1078 1079 1080 .. 5022

All times are in UTC.