2024/04/30

Newest at the top

2024-04-30 22:27:29 +0200mreh(~matthew@host86-160-168-68.range86-160.btcentralplus.com) (Ping timeout: 252 seconds)
2024-04-30 22:27:13 +0200 <lambdabot> Integral a => a -> [a]
2024-04-30 22:27:12 +0200 <EvanR> :t factor
2024-04-30 22:26:35 +0200 <lambdabot> [2,2,2,11,23]
2024-04-30 22:26:34 +0200 <tomsmeding> > factor 2024
2024-04-30 22:26:11 +0200 <monochrom> cool fusion
2024-04-30 22:25:35 +0200 <EvanR> that would be cool
2024-04-30 22:24:52 +0200 <mauke> we did it. we solved coldfusion
2024-04-30 22:24:44 +0200philopsos(~caecilius@user/philopsos) (Ping timeout: 252 seconds)
2024-04-30 22:24:29 +0200tri(~tri@ool-18bbef1a.static.optonline.net)
2024-04-30 22:24:09 +0200 <EvanR> 2024 CF
2024-04-30 22:23:58 +0200 <EvanR> 23 C times 88 F equals
2024-04-30 22:23:34 +0200 <tomsmeding> if the other number was supposed to be fahrenheit then 88 is also kind of on the hot side :p
2024-04-30 22:23:14 +0200 <lambdabot> 17
2024-04-30 22:23:13 +0200 <mauke> > 17 .&. 119
2024-04-30 22:22:26 +0200 <EvanR> 23... 17... which are also reasonable temperatures C
2024-04-30 22:22:02 +0200 <tomsmeding> 1. 88 is not prime, 2. what does the temperature have to do with prime factors
2024-04-30 22:21:38 +0200 <EvanR> I thought we were doing prime factors of calendar years
2024-04-30 22:20:42 +0200tomsmedingis confused
2024-04-30 22:20:22 +0200 <EvanR> must be hotter than I thought outside today
2024-04-30 22:20:14 +0200 <lambdabot> 2023
2024-04-30 22:20:12 +0200 <EvanR> > 17 * 119
2024-04-30 22:20:08 +0200 <lambdabot> from the context: (Num a, Num (a -> b))
2024-04-30 22:20:08 +0200 <lambdabot> • Could not deduce (Num a0)
2024-04-30 22:20:08 +0200 <lambdabot> error:
2024-04-30 22:20:07 +0200 <EvanR> > 17 & 119
2024-04-30 22:18:05 +0200 <lambdabot> 2024
2024-04-30 22:18:04 +0200 <tomsmeding> > 23 * 88
2024-04-30 22:17:15 +0200mwnaylor(~user@2601:5cf:837e:2bb0::f472)
2024-04-30 22:15:17 +0200_ht(~Thunderbi@28-52-174-82.ftth.glasoperator.nl) (Remote host closed the connection)
2024-04-30 22:08:00 +0200 <lambdabot> 23
2024-04-30 22:07:59 +0200 <mauke> > 2024 `div` 88
2024-04-30 22:00:11 +0200 <int-e> Increasing -F is also a possibility I guess, but it feels like a rather blunt tool.
2024-04-30 21:59:14 +0200 <tomsmeding> int-e: at least for the program in question, -G3 doesn't help
2024-04-30 21:58:12 +0200 <mauke> https://downloads.haskell.org/ghc/latest/docs/users_guide/runtime_control.html#rts-options-to-cont…
2024-04-30 21:56:53 +0200 <int-e> (RTS option to set the number of generations)
2024-04-30 21:56:36 +0200 <int-e> does -G 3 ever help with this kind of repeated GC?
2024-04-30 21:56:32 +0200 <tomsmeding> it would just make it harder to believe that the claims we're making about how the algorithms work actually work in practice
2024-04-30 21:56:31 +0200 <monochrom> OK, but the reference implementation is allowed to be slow. :)
2024-04-30 21:56:28 +0200sawilagar(~sawilagar@user/sawilagar)
2024-04-30 21:56:09 +0200 <tomsmeding> I could also just not write the implementation and the paper would not be much weaker
2024-04-30 21:55:53 +0200 <tomsmeding> the reference implementation is there to show that the essence of the algorithm that we get halfway is not nonsense
2024-04-30 21:55:32 +0200 <tomsmeding> monochrom: the point of the paper is that it optimises a really crappy algorithm from theory to a known fast thing
2024-04-30 21:55:03 +0200 <monochrom> Um ideally a paper is not supposed to contrive things just for the sake of "interesting" and "new". At least, one can hope...
2024-04-30 21:55:00 +0200 <EvanR> you already know that's 1. the slow part and 2. going to be too slow
2024-04-30 21:54:58 +0200 <tomsmeding> my structure doesn't even have any cycles, you could reference count GC it and all would be good!
2024-04-30 21:54:41 +0200 <EvanR> worrying about the performance of adding to a compact region seems like,
2024-04-30 21:54:24 +0200 <tomsmeding> mauke: that's a neat quote for that
2024-04-30 21:53:35 +0200 <mauke> by which I mean that under a copying collector, anything not traversed (and copied) will be collected implicitly
2024-04-30 21:53:29 +0200benjaminl(~benjaminl@user/benjaminl)