2025/01/10

Newest at the top

2025-01-10 23:53:01 +0100 <c_wraith> euouae: did you ever get an answer to that? It turns out there are very sneaky ways.
2025-01-10 23:51:29 +0100mchav(~mchav@197.221.254.145) (Quit: Client closed)
2025-01-10 23:51:23 +0100peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 252 seconds)
2025-01-10 23:49:11 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds)
2025-01-10 23:46:29 +0100target_i(~target_i@user/target-i/x-6023099) (Quit: leaving)
2025-01-10 23:44:11 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) merijn
2025-01-10 23:41:11 +0100JuanDaugherty(~juan@user/JuanDaugherty) JuanDaugherty
2025-01-10 23:40:45 +0100mari51520(~mari-este@user/mari-estel) (Remote host closed the connection)
2025-01-10 23:33:26 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds)
2025-01-10 23:28:49 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) merijn
2025-01-10 23:28:34 +0100Tuplanolla(~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) Tuplanolla
2025-01-10 23:27:14 +0100peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich
2025-01-10 23:25:39 +0100__monty__(~toonn@user/toonn) (Quit: leaving)
2025-01-10 23:22:53 +0100housemate(~housemate@2a04:9dc0:0:162::5d91:d7ed) (Remote host closed the connection)
2025-01-10 23:22:34 +0100housemate(~housemate@2a04:9dc0:0:162::5d91:d7ed) housemate
2025-01-10 23:21:24 +0100housemate(~housemate@2a04:9dc0:0:162::5d91:d7ed) (Remote host closed the connection)
2025-01-10 23:20:30 +0100housemate(~housemate@2a04:9dc0:0:162::5d91:d7ed) housemate
2025-01-10 23:19:53 +0100housemate(~housemate@2a04:9dc0:0:162::5d91:d7ed) (Remote host closed the connection)
2025-01-10 23:18:58 +0100housemate(~housemate@2a04:9dc0:0:162::5d91:d7ed) housemate
2025-01-10 23:18:23 +0100housemate(~housemate@2a04:9dc0:0:162::5d91:d7ed) (Remote host closed the connection)
2025-01-10 23:17:48 +0100housemate(~housemate@2a04:9dc0:0:162::5d91:d7ed) housemate
2025-01-10 23:17:46 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds)
2025-01-10 23:16:50 +0100housemate(~housemate@2a04:9dc0:0:162::5d91:d7ed) (Max SendQ exceeded)
2025-01-10 23:15:45 +0100housemate(~housemate@2a04:9dc0:0:162::5d91:d7ed) housemate
2025-01-10 23:14:49 +0100ahisho(~ahisoooo@88.90.222.87.dynamic.jazztel.es)
2025-01-10 23:14:44 +0100 <euouae> & it won't be -- I still wanted to know (perhaps curiosity) how to produce the rationals without duplicates
2025-01-10 23:14:36 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2025-01-10 23:14:09 +0100 <euouae> mari51520: yes that's true. it's just an enumeration of the rationals, it doesn't need to be in the middle of it
2025-01-10 23:12:29 +0100 <mari51520> that looks like it could be just another input to it
2025-01-10 23:11:44 +0100 <mari51520> do you need that to be in the middle of the crunching euouae?
2025-01-10 23:11:34 +0100 <mchav> That'll give you a sense of how the approach will scale.
2025-01-10 23:11:23 +0100 <mchav> Well if you try it and get the performance under control it'll make for a lot of learning. I would still say do a prototype on your machine and profile it.
2025-01-10 23:10:46 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) merijn
2025-01-10 23:10:21 +0100 <euouae> because the paper has Haskell pseudo-code to explain its concepts... call me easily influenceable
2025-01-10 23:09:54 +0100 <euouae> I was reading this paper <https://www.cs.ox.ac.uk/people/jeremy.gibbons/publications/rationals.pdf> which I need in some small part in my code, and it sort of made me think about doing it all in Haskell for the fun of it
2025-01-10 23:09:13 +0100 <euouae> Yeah fair enough. I'm fairly good at reasoning with C++ so I don't need to involve Haskell to end up having to write expert-level Haskell for it
2025-01-10 23:08:20 +0100 <mchav> Well I would still profile the run. I've been working on a dataframe library and I find I REALLY have to be careful to avoid copies. Intuitive/readable Haskell ends up being a memory hog. Or maybe I'm not that good at writing it. I don't know how this changes when you use something that FFIs to C and how GHC will then deal with pinned memory etc.
2025-01-10 23:07:35 +0100 <mari51520> the interface will not need much logic anyways
2025-01-10 23:06:01 +0100 <euouae> Ah -- memory-wise. hm... OK fine. Maybe I'll do it in C++.
2025-01-10 23:05:31 +0100 <mchav> Memory and as result money, I guess. Have you profiled a sample implementation on your computer?
2025-01-10 23:05:00 +0100 <euouae> does the jumpstart matter?
2025-01-10 23:04:49 +0100 <euouae> mchav, OK but what do you mean costly? If my computations need 1+hr each?
2025-01-10 23:04:37 +0100 <mari51520> well but it makes sense to have a server for crunching and another for haskell
2025-01-10 23:04:32 +0100 <mchav> *GHC
2025-01-10 23:04:24 +0100 <mchav> Haskell is really heavy-handed for this sort of thing. It'll be costly just to have Haskell running on each instance.
2025-01-10 23:03:43 +0100 <euouae> also, for fun
2025-01-10 23:03:29 +0100 <euouae> I'm expecting Haskell to simplify the MPI integration
2025-01-10 23:03:24 +0100 <euouae> openMP is for single-host. if you want multi-host you need MPI. I don't have that code
2025-01-10 23:03:18 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
2025-01-10 23:03:14 +0100 <haskellbridge> <magic_rb> But id recommend equinix or hetznee, theyre cheaper and more simple. Also youre not helping jeff bazos