<mdln>Not sure who it was specifically, but wasn't someone working with guile/guix in the context of containers (ie Docker or CoreOS Rkt)? *nalaginrut compiled tinyscheme with emscripten to JS and run successfully, maybe it's a chance to write web frontend in Scheme too <zacts>now that I'm learning Latin, everytime I read guile, I think Gallia, or Gaul <nalaginrut>I've been always wondering what folks pronounce "guile" ;-P <mdln>My natural reaction was to pronounce it guy-al <mdln>nalaginrut: I've been meaning to test out Artanis and compare it with other systems, but I'm pretty set on using it to replace the various stacks I've been using. You might see some messy commits from me in the near future :) <nalaginrut>mdln: and I would suggest you start with small changes, since there'll be large change after 0.1 released <nalaginrut>bur fortunately, low-level API may not change a lot <mdln>Excellent, I'll add that to my notes <nalaginrut>mark_weaver: fortunately! I never make it wrong ;-D <nalaginrut>many guys pronounce it /gil/, but I read it as /gail/ when I first time saw it ;-) <mark_weaver>yeah, I guess that many people who aren't native english speakers would pronounce it /gil/ <mark_weaver>there's no small set of rules to know how to pronounce english words. it requires massive amounts of memorization. <nalaginrut>sometimes I thought they're talking about GIL... heh ;-P ***michel_mno_afk is now known as michel_mno
<mark_weaver>it's actually pronounced /ɡaɪl/, which sounds like guy-al, as you suggested. <lloda>hello mark_weaver, would you call this a bug? <lloda>scheme@(guile-user)> (import (rnrs bytevectors)) <lloda>scheme@(guile-user)> (define b #u8(0 0 0 0 0 0 248 255)) <lloda>scheme@(guile-user)> (bytevector-ieee-double-native-ref b 0) <lloda>scheme@(guile-user)> (log $1) <lloda>$2 = +nan.0+3.141592653589793i <ijp>interesting imaginary part there <lloda>it ignores the sign of the nan when printing, but not when doing the log <wleslie>ijp: e^{i \\pi} + 1 = 0 => log(-x) = log(|x|) + i \\pi : x \\in \\R <ijp>wleslie: I know how to extend logs and exponentials to complex numbers. What I'm surprised by is it being extended to NaNs <ijp>more specifically, that it isn't returning a Nan or NaN+Nan <wleslie>because NaN feels like it taints things <lloda>it's log_of_shifted_double() in numbers.c, it does the straight thing without looking at nan-or-not: <lloda>log_of_shifted_double (double x, long shift) <lloda> double ans = log (fabs (x)) + shift * M_LN2; <lloda> if (copysign (1.0, x) > 0.0) <lloda> return scm_i_from_double (ans); <lloda> return scm_c_make_rectangular (ans, M_PI); <lloda>for a counterpoint, (sqrt $1) => +nan.0, here is what scm_sqrt() does: <lloda> double xx = scm_to_double (z); <lloda> return scm_c_make_rectangular (0.0, sqrt (-xx)); <lloda> return scm_i_from_double (sqrt (xx)); <lloda>of course, xx<0 is false for any nan <lloda>diagnostic: pointless use of copysign <mark_weaver>I agree that the handling of NaNs is suboptimal though. <mark_weaver>as for the disagreement with sqrt, it's because sqrt(-0.0) is explicitly specified to be +0.0. <mark_weaver>don't look for rigorous mathematical consistency in the handling of signed zeroes. for better or for worse, they were designed pragmatically by people who know a lot more about numerical algorithms than probably any of us. <mark_weaver>I have mixed feelings about them myself, but I have read enough to convince myself that I don't know enough to override the wisdom of IEEE-754. <mark_weaver>the thing is, inexact arithmetic itself is not mathematically consistent. <mark_weaver>as soon as you use inexacts at all, you are already in very messy territory. there's no avoiding it. <mark_weaver>signed zeroes are all about handling underflows such that most of the time there is no discontinuous jump in some result that doesn't make sense. <lloda>my bad, I see -0 vs +0 makes sense for both log and sqrt, I hadn't thought so far <lloda>what about special-casing nan in log_of_shifted_double? ***michel_mno is now known as michel_mno_afk
***michel_mno_afk is now known as michel_mno
***michel_mno is now known as michel_mno_afk
<mark_weaver>lloda: I thought about it some more, and I don't think it's worth special casing NaN in log_of_shifted_double. <mark_weaver>it would so down 'log' with no advantage that I can see <mark_weaver>a complex number is a NaN if _either_ component is a NaN. <mark_weaver>allow me to give an example that confused me at first but now I understand: <mark_weaver>one of the Annexes of C11 and C++11 specify that the result shall be +nan.0+inf.0 for something that is mathematically a complex infinity with indefinite phase. <mark_weaver>I actually complained about this, on the grounds that it should rather be +nan.0+nan.0i, because it doesn't make sense to say that the imaginary part is positive. <mark_weaver>but the idea is that this is a result that is both an infinity and a NaN. <mark_weaver>whereas +nan.0+nan.0i would not be considered an infinity. <mark_weaver>and when working on the riemann sphere, +nan.0+inf.0i is actually known to be the point at infinity. <mark_weaver>"Values with an infinite imaginary part are projected to positive infinity on the real axis, even if the real part is NaN." <mark_weaver>so, I can see why this is actually useful when writing numerical algorithms that work on the Riemann sphere. <mark_weaver>and if we accept that +nan.0+inf.0i is considered a complex infinity of indefinite phase, then I really don't see a reason to worry about +nan.0+3.141592653589793i <ijp>davexunit: because getting rewinding to work right is really annoying <ijp>it's also a pretty complicated thing to have as a primitive <mark_weaver>it might be possible to implement dynamic-wind and continuations-that-honor-it in terms of more primitive continuations that don't support dynamic-wind. <mark_weaver>I have a vague recollection of reading in a paper that it was possible to do that, but it's possible I'm misremembering. <ijp>you can, I think scheme48 did it this way