Home freenode/#haskell: Logs Calendar

Logs: freenode/#haskell

←Prev  Next→
Page 1 .. 559 560 561 562 563 564 565 566 567 568 569 .. 5022
— 502,152 events total
2020-10-10 17:33:27 × thir quits (~thir@p200300f27f02580060eb7dde324e54c8.dip0.t-ipconnect.de) (Ping timeout: 260 seconds)
2020-10-10 17:34:08 × vicfred quits (~vicfred@unaffiliated/vicfred) (Remote host closed the connection)
2020-10-10 17:37:19 <frdg> what is a known algorithm to determine if a relation, ie `[ (a,a) ]` is reflexive? I can hack it but I am looking for a nicer solution.
2020-10-10 17:40:04 → dcbdnl joins (~dcbdnl@2601:2c6:4e00:1630:4685:ff:fecf:3992)
2020-10-10 17:41:17 → avdb joins (~avdb@ip-213-49-124-97.dsl.scarlet.be)
2020-10-10 17:41:50 × GyroW quits (~GyroW@unaffiliated/gyrow) (Remote host closed the connection)
2020-10-10 17:42:08 → GyroW joins (~GyroW@ptr-48ujrfd1ztq5fjywfw3.18120a2.ip6.access.telenet.be)
2020-10-10 17:42:09 × GyroW quits (~GyroW@ptr-48ujrfd1ztq5fjywfw3.18120a2.ip6.access.telenet.be) (Changing host)
2020-10-10 17:42:09 → GyroW joins (~GyroW@unaffiliated/gyrow)
2020-10-10 17:42:35 → geekosaur joins (82659a05@host154-005.vpn.uakron.edu)
2020-10-10 17:44:48 → bifunc2 joins (bifunc2@gateway/vpn/protonvpn/bifunc2)
2020-10-10 17:45:22 <bifunc2> With cereal (serialization library) I'm finding deserializing Word64s is much faster than deserializing Doubles. Is this something you'd expect?
2020-10-10 17:46:23 × cole-h quits (~cole-h@c-73-48-197-220.hsd1.ca.comcast.net) (Quit: Goodbye)
2020-10-10 17:47:22 → cole-h joins (~cole-h@c-73-48-197-220.hsd1.ca.comcast.net)
2020-10-10 17:49:01 × cosimone quits (~cosimone@2001:b07:ae5:db26:a16f:75:586:b3b0) (Quit: cosimone)
2020-10-10 17:52:54 × bitmapper quits (uid464869@gateway/web/irccloud.com/x-bpsvglwvvorbcbrp) (Quit: Connection closed for inactivity)
2020-10-10 17:53:39 → vicfred joins (~vicfred@unaffiliated/vicfred)
2020-10-10 17:54:53 ← sm[m] parts (simonmicma@gateway/shell/matrix.org/x-tneitzltqviyrfjn) ("User left")
2020-10-10 17:55:36 → sm[m] joins (simonmicma@gateway/shell/matrix.org/x-tneitzltqviyrfjn)
2020-10-10 17:58:49 <c_wraith> Depends on the serialization format. I don't know what cereal uses.
2020-10-10 17:59:44 × bifunc2 quits (bifunc2@gateway/vpn/protonvpn/bifunc2) (Remote host closed the connection)
2020-10-10 18:00:02 × Guest982 quits (~hollowlev@185.163.110.116) ()
2020-10-10 18:00:53 → gnar^2 joins (~user@c-73-118-153-248.hsd1.wa.comcast.net)
2020-10-10 18:01:20 → bifunc2 joins (bifunc2@gateway/vpn/protonvpn/bifunc2)
2020-10-10 18:01:26 <koz_> frdg: For totally arbitrary relations, the only way to 'determine' this is if the relation is finitary.
2020-10-10 18:01:38 <bifunc2> c_wraith sorry, i forgot to mention i'm doing big-endian for both
2020-10-10 18:02:30 <bifunc2> (btw i got disconnected there for a while and may not have seen some messages)
2020-10-10 18:02:35 <c_wraith> bifunc2: ok... the short answer is "yes", especially if you're doing millions of them.
2020-10-10 18:02:55 <c_wraith> bifunc2: https://hackage.haskell.org/package/cereal-0.5.8.1/docs/src/Data.Serialize.IEEE754.html#wordToDouble
2020-10-10 18:03:44 × gnar^2 quits (~user@c-73-118-153-248.hsd1.wa.comcast.net) (Remote host closed the connection)
2020-10-10 18:03:57 → gnar^2 joins (~user@c-73-118-153-248.hsd1.wa.comcast.net)
2020-10-10 18:04:10 <c_wraith> bifunc2: that call to alloca is a problem for performance, because it's part of the FFI
2020-10-10 18:04:41 <c_wraith> bifunc2: it has to put it in a separate memory space (outside the nursery) because it needs a stable address in case it's passed to C code
2020-10-10 18:05:12 → sand_dull joins (~theuser@104.140.53.43)
2020-10-10 18:05:24 <c_wraith> bifunc2: that means both allocating and collecting it are going to be slower than they would be for something managed entirely in GHC's nursery
2020-10-10 18:05:31 ← dcbdnl parts (~dcbdnl@2601:2c6:4e00:1630:4685:ff:fecf:3992) ("Good Bye")
2020-10-10 18:05:52 <bifunc2> c_wraith has nobody (other than cereal) made anything faster yet?
2020-10-10 18:07:45 <dolio> The new binary might be faster, but it uses a particular format, not just 'whatever bits you want to spit out'.
2020-10-10 18:07:49 → Alleria_ joins (~AllahuAkb@2604:2000:1484:26:d9b5:40ce:4a6a:3e0a)
2020-10-10 18:08:37 × avdb quits (~avdb@ip-213-49-124-97.dsl.scarlet.be) (Quit: WeeChat 2.9)
2020-10-10 18:08:58 <dolio> I guess it's called cborg now?
2020-10-10 18:09:17 → thir joins (~thir@p200300f27f02580060eb7dde324e54c8.dip0.t-ipconnect.de)
2020-10-10 18:09:17 <dolio> Or serialise?
2020-10-10 18:09:55 × _Alleria quits (~AllahuAkb@2604:2000:1484:26:40a5:ffd0:b706:8d98) (Ping timeout: 240 seconds)
2020-10-10 18:09:57 <bifunc2> hmm, no idea..
2020-10-10 18:10:40 <ghoulguy> I think one is the format: cborg and the other is a serialization library using that: serialise
2020-10-10 18:10:56 <ghoulguy> I like that better as other languages have libraries to read cbor
2020-10-10 18:11:07 <dolio> Yeah.
2020-10-10 18:11:29 <dolio> Anyhow, my understanding is that their technique for implementation is more reliable, too.
2020-10-10 18:11:48 <bifunc2> hmm cereal is not just standard? big-endian for word64 is standard. it uses IEEE754 for doubles
2020-10-10 18:12:01 × mirrorbird quits (~psutcliff@2a00:801:429:5ea0:80af:2bca:f885:1bb9) (Ping timeout: 272 seconds)
2020-10-10 18:12:05 × djellemah quits (~djellemah@c-73-12-31-179.hsd1.va.comcast.net) (Ping timeout: 240 seconds)
2020-10-10 18:12:25 <ghoulguy> cereal is legacy, I would advise people not to use it, it's unmaintained and there's really no reason not to use binary if you don't care much about how you serialize things
2020-10-10 18:13:16 <dolio> The only reason I ever hear for using cereal is, "it's required for this other library," and usually by people who are telling me because they'd rather not use cereal.
2020-10-10 18:13:25 × DavidEichmann quits (~david@43.240.198.146.dyn.plus.net) (Ping timeout: 240 seconds)
2020-10-10 18:13:28 <dolio> Lately, that is.
2020-10-10 18:13:29 <bifunc2> ah, i did not know that, thanks!
2020-10-10 18:13:41 <bifunc2> Now the question is, "binary" vs. "store"?
2020-10-10 18:13:56 <bifunc2> (for machine representation, where explicit endianess is not important)
2020-10-10 18:15:26 <dolio> Anyhow, one of the other advantages of serialise/cborg, in my understanding, is that they wrote it so that only a fixed loop (which is part of the package) needs to be well optimized by GHC.
2020-10-10 18:16:06 → jedws joins (~jedws@121.209.161.98)
2020-10-10 18:16:17 <dolio> And that is relatively reliable, whereas the old binary/cereal relied on whatever instances anyone wrote to be optimized in each end-program, which is less reliable.
2020-10-10 18:16:54 <dolio> So in principle, binary might be slightly faster if everything goes according to plan, but often it doesn't.
2020-10-10 18:17:14 <dolio> And you have to put in more effort to make sure it does.
2020-10-10 18:18:28 → shatriff joins (~vitaliish@130.180.217.140)
2020-10-10 18:19:04 <dolio> It's like the usual, "I could write faster assembly code than a compiler," but then you don't.
2020-10-10 18:19:27 × thir quits (~thir@p200300f27f02580060eb7dde324e54c8.dip0.t-ipconnect.de) (Ping timeout: 240 seconds)
2020-10-10 18:19:46 <c_wraith> I'm really surprised GHC.Exts doesn't export primops for Double# <-> Word64# and Float# <-> Word32# that just ship bytes back and forth instead of doing numeric conversions
2020-10-10 18:21:13 <dolio> I've got `Word# -> Double#` in GHC.Prim (but not the reverse).
2020-10-10 18:21:40 <dolio> Not sure how that actually makes reliable sense.
2020-10-10 18:21:46 → litenull joins (~litenull@185.204.1.185)
2020-10-10 18:22:16 × elliott_ quits (~elliott@pool-108-51-141-12.washdc.fios.verizon.net) (Ping timeout: 246 seconds)
2020-10-10 18:22:17 → mirrorbird joins (~psutcliff@2a00:801:429:5ea0:80af:2bca:f885:1bb9)
2020-10-10 18:22:21 <c_wraith> I'm pretty sure that is a numeric conversion, not byte-shipping
2020-10-10 18:22:37 <dolio> Oh, that makes sense.
2020-10-10 18:23:28 <dolio> I guess you need to make byte arrays to convert.
2020-10-10 18:23:31 <phadej> Does even C make it easy, or is the way is to use `union { .. }` /
2020-10-10 18:23:43 <c_wraith> union is the only correct way in C
2020-10-10 18:23:55 <c_wraith> But at least that can be done on the stack
2020-10-10 18:23:58 hackage hwk 0.2.0 - A modern Haskell based AWK replacement https://hackage.haskell.org/package/hwk-0.2.0 (JensPetersen)
2020-10-10 18:24:05 × wroathe quits (~wroathe@c-73-24-27-54.hsd1.mn.comcast.net) (Ping timeout: 240 seconds)
2020-10-10 18:24:21 <dolio> I don't think that's actually guaranteed to work in C>
2020-10-10 18:24:30 <dolio> It would be implementation dependent.
2020-10-10 18:25:29 → Codaraxis_ joins (~Codaraxis@ip68-5-90-227.oc.oc.cox.net)
2020-10-10 18:26:16 → Tops2 joins (~Tobias@dyndsl-095-033-016-225.ewe-ip-backbone.de)
2020-10-10 18:26:57 × _xor quits (~xor@74.215.46.133) (Quit: WeeChat 2.9)
2020-10-10 18:27:06 → fresheyeball joins (~isaac@c-71-237-105-37.hsd1.co.comcast.net)
2020-10-10 18:27:27 × Codaraxis quits (~Codaraxis@ip68-5-90-227.oc.oc.cox.net) (Ping timeout: 240 seconds)
2020-10-10 18:27:36 <c_wraith> Prelude GHC.Exts> D# (word2Double# 3##) -> 3.0
2020-10-10 18:27:51 <dolio> Okay, yeah.
2020-10-10 18:27:59 <dolio> That explains why the reverse doesn't exist.
2020-10-10 18:28:00 × snakemas1 quits (~snakemast@213.100.206.23) (Ping timeout: 256 seconds)
2020-10-10 18:28:04 <c_wraith> Today I learned the syntax for Word# and Double# literals
2020-10-10 18:28:41 → snakemas1 joins (~snakemast@213.100.206.23)
2020-10-10 18:29:54 <c_wraith> Amusingly, the name Double# tells you what the syntax is.
2020-10-10 18:30:29 × geekosaur quits (82659a05@host154-005.vpn.uakron.edu) (Ping timeout: 245 seconds)
2020-10-10 18:30:36 × heatsink_ quits (~heatsink@107-136-5-69.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection)
2020-10-10 18:30:48 <bifunc2> I'm finding deserializing Word64s 10x slower on binary than cereal
2020-10-10 18:30:49 × Tario quits (~Tario@201.192.165.173) (Read error: Connection reset by peer)
2020-10-10 18:30:59 <bifunc2> Double deserialization is 2x slower on binary
←Prev  Next→
Page 1 .. 559 560 561 562 563 564 565 566 567 568 569 .. 5022

All times are in UTC.