IRC channel logs


back to list of logs

<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>also, a DOM framework of Scheme is needed
<nalaginrut>or maybe just a wrapper of jquery
<mdln>please no
<nalaginrut>zacts: I read it as "gai:l"
<nalaginrut>I've been always wondering what folks pronounce "guile" ;-P
<mdln>My natural reaction was to pronounce it guy-al
<nalaginrut>yeah, similar to me
<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: oh, thank you very much!
<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
<mark_weaver>nalaginrut: guile is pronounced /ɡaɪl/
<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>it's probably not important
<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
<mdln>Geel (heel)
<mark_weaver>right, that's written in IPA as /gil/
<mark_weaver>but that's not actually how guile is pronounced.
<mark_weaver>it's actually pronounced /ɡaɪl/, which sounds like guy-al, as you suggested.
<mark_weaver>i.e. it rhymes with pile, tile, style, etc.
<civodul>Hello Guilers!
<artyom-poptsov>Hello civodul
<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>$1 = +nan.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
<wingo>sounds like a bug to me
<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>NaN+NaN would make a lot more sense
<wleslie>because NaN feels like it taints things
<ijp>it's supposed to
<wleslie>'t should, but 't ain't.
<lloda>it's log_of_shifted_double() in numbers.c, it does the straight thing without looking at nan-or-not:
<lloda>static SCM
<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> else
<lloda> return scm_c_make_rectangular (ans, M_PI);
<lloda>for a counterpoint, (sqrt $1) => +nan.0, here is what scm_sqrt() does:
<lloda> {
<lloda> double xx = scm_to_double (z);
<lloda> if (xx < 0)
<lloda> return scm_c_make_rectangular (0.0, sqrt (-xx));
<lloda> else
<lloda> return scm_i_from_double (sqrt (xx));
<lloda> }
<lloda>of course, xx<0 is false for any nan
<lloda>diagnostic: pointless use of copysign
<mark_weaver>lloda: it's not pointless.
<mark_weaver>we use copysign to handle -0.0 vs +0.0
<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.
<mark_weaver>but you can't get it right in every case
<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?
<mark_weaver>lloda: yeah, that's probably a good idea, I guess.
***michel_mno is now known as michel_mno_afk
***michel_mno_afk is now known as michel_mno
<dsmith-work>Morning Greetings, Guilers
***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>so +nan.0+3.141592653589793i 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>see the definition of cproj in the C library.
<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
<mark_weaver>does that make sense?
<ijp>I hate dynamic wind
<ijp>davexunit: because getting rewinding to work right is really annoying
<davexunit>fair enough!
<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