2025/09/16

Newest at the top

2025-09-16 20:49:11 +0200 <Guest14> it says something about "signed zeros"
2025-09-16 20:48:28 +0200 <monochrom> I forgot what else. Consult IEEE 754 for the complete list.
2025-09-16 20:48:28 +0200 <Guest14> afikt all the arithmetric opperations are + and *
2025-09-16 20:48:14 +0200 <Guest14> ill see if there are any powers
2025-09-16 20:48:09 +0200 <Guest14> there is a tanh
2025-09-16 20:47:57 +0200 <monochrom> asin acos atan etc can also give NaN for the same reason as sqrt
2025-09-16 20:47:28 +0200 <int-e> anyway the bit og information that there are no divisions is quite useless
2025-09-16 20:47:13 +0200 <Guest14> Returns True if the operand is a negative number, negative infinity, negative zero, or a NaN with negative sign bit.
2025-09-16 20:47:13 +0200 <Guest14> https://hackage.haskell.org › package › fp-ieee › docs
2025-09-16 20:47:12 +0200 <Guest14> Hackage
2025-09-16 20:47:12 +0200 <Guest14> on google i find:
2025-09-16 20:47:06 +0200arandombit(~arandombi@user/arandombit) arandombit
2025-09-16 20:46:38 +0200 <Guest14> it seems to appear when the input is a very small negative number
2025-09-16 20:46:16 +0200 <Guest14> this is guarded against
2025-09-16 20:46:16 +0200 <monochrom> Ooops.
2025-09-16 20:46:14 +0200 <Franciman> indeed...
2025-09-16 20:46:08 +0200 <int-e> Well, there's 0/0
2025-09-16 20:45:55 +0200 <monochrom> division produces Inf.
2025-09-16 20:45:45 +0200vanishingideal(~vanishing@user/vanishingideal) vanishingideal
2025-09-16 20:45:44 +0200 <monochrom> Actually division doesn't produce NaN. But sqrt does.
2025-09-16 20:45:40 +0200arandombit(~arandombi@user/arandombit) (Ping timeout: 256 seconds)
2025-09-16 20:45:23 +0200 <Guest14> how is it producing a NaN
2025-09-16 20:45:14 +0200 <Guest14> the code does not have *any divisions*
2025-09-16 20:45:03 +0200 <Guest14> https://paste.tomsmeding.com/ltFVsS2E
2025-09-16 20:45:03 +0200 <Guest14> im getting a strange error;
2025-09-16 20:44:23 +0200Guest14(~Guest91@2a0a:ef40:50c:3901:79f5:d78f:9aec:1a09)
2025-09-16 20:41:16 +0200arandombit(~arandombi@user/arandombit) arandombit
2025-09-16 20:40:34 +0200poscat0x04(~poscat@user/poscat) (Ping timeout: 256 seconds)
2025-09-16 20:39:57 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds)
2025-09-16 20:39:22 +0200arandombit(~arandombi@user/arandombit) (Ping timeout: 248 seconds)
2025-09-16 20:38:59 +0200poscat(~poscat@user/poscat) poscat
2025-09-16 20:38:03 +0200 <monochrom> Lambda The Ultimate Callback Programming
2025-09-16 20:37:51 +0200tomsmeding. o O ( (a -> r) -> (Error -> r) -> Promise a -> r )
2025-09-16 20:37:24 +0200 <tomsmeding> though I guess Promise is more like a Church-encoded Either
2025-09-16 20:36:51 +0200 <monochrom> Yeah
2025-09-16 20:36:17 +0200 <tomsmeding> the JS tendency is mostly because they use one or two monads without knowing that they're monads, and you get continuations from (>>=) :p
2025-09-16 20:35:29 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-09-16 20:35:20 +0200 <tomsmeding> elsewhere non-tail-call callbacks are more common I feel
2025-09-16 20:35:06 +0200 <tomsmeding> in the javascript world, a callback is typically something that's tail-called -- i.e. what we'd call a continuation
2025-09-16 20:29:48 +0200target_i(~target_i@user/target-i/x-6023099) target_i
2025-09-16 20:26:05 +0200GdeVolpiano(~GdeVolpia@user/GdeVolpiano) GdeVolpiano
2025-09-16 20:24:43 +0200divlamir(~divlamir@user/divlamir) divlamir
2025-09-16 20:24:42 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds)
2025-09-16 20:24:24 +0200divlamir(~divlamir@user/divlamir) (Read error: Connection reset by peer)
2025-09-16 20:23:35 +0200 <monochrom> OK sometimes it's a->r instead of a -> IO b.
2025-09-16 20:22:55 +0200 <monochrom> IMO continuation = callback = a -> IO b too.
2025-09-16 20:20:06 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-09-16 20:15:03 +0200meejah_meejah
2025-09-16 20:13:22 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds)
2025-09-16 20:10:37 +0200Googulator(~Googulato@2a01-036d-0106-217b-9021-558a-ccea-f5e8.pool6.digikabel.hu)