IRC channel logs

2014-04-24.log

back to list of logs

<zacts>lo
<rlb>evening
<rlb>(or whatever)
<nalaginrut>morning guilers~
<zacts>lo
<civodul>Hello Guilers!
<wingo>morning civodul :)
<civodul>i experience the --program-suffix bug we were discussing the other day: https://lists.gnu.org/archive/html/autoconf/2014-04/msg00010.html
<civodul>hopefully a fix will follow :-)
*taylanub resorts to printf debugging for the (make-polar 1 -0.0) => 1.0+0.0i problem :\\
<nalaginrut>taylanub: it's fine in master
<taylanub>gdb doesn't seem to become aware of loaded .dylib files, lldb fails to inspect the stack variables (maybe becuse of optimization, bug happens with -O2)
<taylanub>nalaginrut: on OS X ?
<nalaginrut>hmm, Linux here
<taylanub>the code of scm_c_make_polar doesn't seem to have changed on master since 2.0.11 so presumably the bug would persist; if not, it would mean it disappeared by "chance" which isn't nice, it's probably best to find out the reason
<taylanub>I *am* having success with printf debugging by the way, what should be -0.0 prints as a positive 0.0!
<taylanub>the result of sin(ang) that is
<nalaginrut>well, it's hard for me to find a OS X for testing ;=)
<ijp>taylanub: you mean make-rectangular
<ijp>well, no, they should be the same here
<taylanub>ijp: scm_c_make_polar receives -0.0 for its `double ang' argument, declares a `double s' and does `s = sin (ang)', and s ends up 0.0 instead of -0.0
<taylanub>since I can't reproduce this with a very simple test C program that also does sin (-0.0), I'm trying to figure out now what extra flags are passed to gcc other than -O2 ..
<taylanub>doesn't seem to lie in the flags either, I guess my test-case isn't near enough to the code.
<taylanub>heh, apparently memcpy() isn't enough obfuscation to prevent constant-propagation or something, I can reproduce the problem with a simple program now: http://sprunge.us/QfhM
<ijp> http://java.metagno.me/
<ijp>I can't do significantly better than guessing
<zacts>morning guile hackers
<wingo>ijp: i tried too, failed pretty much all the time
<dsmith-work>taylanub: Does -0.0 actually work?
<dsmith-work>I had a -0 problem once, and I was't able to create a literal constant directly like that.
<dsmith-work>taylanub: THAT may have been a bug in my compiler..
<taylanub>dsmith-work: You mean in C ? Not sure what the standards say but it works with GCC.
<taylanub>dsmith-work: -0 on the other hand doesn't exist AFAIK, neither in C nor Guile Scheme.
<dsmith-work>Yeah, C.
<taylanub>(To be more specific, integer types in C and exact numbers in Scheme cannot be negative zero.)
<dsmith-work>Hmm. What if the arch used sign-magnitude instead of 2's complement?
<dsmith-work>(But yes, I understand -0 is not possible for int)
<dsmith-work>It was gcc on a coldfire.
<dsmith-work>taylanub: I was wrong. Works fine on my desktop. "Nevermind"
<taylanub>:)
<wingo>i liked sperber's numerics paper.
<mark_weaver>taylanub: it's great that you found an isolated test case that demonstrated the signed-zero lossage. can you show us the generated assembly code? (and verify that the generated assembly still exhibits the bug)
<taylanub>mark_weaver: This is generated via "gcc-mp-4.8 -O1 -S test.c", and an a.out generated from it via "gcc-mp-4.8 test.s" does have the bug: http://sprunge.us/SZbb
<taylanub>mark_weaver:
<taylanub>whoops, ignore that
<mark_weaver>actually, it might be best to use "objdump -d" on the final executable, in case the linker is doing some kind of link-time-optimization.
<mark_weaver>(an executable that has been shown to exhibit the problem)
<taylanub>Supposedly "otool -tV" is the OS X way of disassembling executables, does this one look fine ? http://sprunge.us/KTCT
*mark_weaver looks
<taylanub>Well GNU binutils installed from MacPorts worked too: http://sprunge.us/bVWG
<mark_weaver>taylanub: neither of those shows me what value is stored at 0x62(%rip), but my guess is that it is negative zero. this makes me guess that the bug is in cexp
<mark_weaver>specifically, cexp(-0.0) should return 0.0-0.0i, but I suspect that on your system it returns 0.0+0.0i.
<mark_weaver>if so, the reason this is sensitive to compiler optimization is because it is those optimizations that combine a 'sin' and 'cos' together into 'cexp'.
<mark_weaver>and the reason it happens on MacOS but not GNU/Linux is because 'cexp' is part of the C library.
<mark_weaver>(well, part of the math library)
<taylanub>cexp (-0.0) seems to return 1.0
<taylanub>The manpage (signed "4th Berkeley Distribution") says "cexp(+-0 + 0i) returns 1 + 0i."
<mark_weaver>oh, sorry, my bad. I meant to write that cexp(-0.0i) should return 1.0-0.0i
<mark_weaver>hmm, is that really not specified by the standards? if so, it could be a bug that GCC is expecting that behavior (although it is sensible and GNU libc does it)
<mark_weaver>oh, well, C11 Annex G does specify that cexp(conj(z)) = conj(cexp(z)), so that should cover this case.
*taylanub understands little of all this :-)
<mark_weaver>conj(a+bi) returns a-bi.
<mark_weaver>if you haven't worked with complex arithmetic before, then there's no reason why you should know this stuff.
<mark_weaver>taylanub: what is cimag(cexp(conj(0.0))) ?
<mark_weaver>(on your system)
<taylanub>-0.0
<taylanub>oh wait, forgot -O1
<taylanub>never mind, didn't, it's -0.0
<mark_weaver>I think you need to inhibit constant propagation, like in your previous self-contained example.
<mark_weaver>it's probably doing the entire computation at compile-time.
<mark_weaver>-O0 might be one way to do it.
<taylanub>oh, I didn't do that for the cexp() test either
<mark_weaver>(in this case, we don't need optimization, because we are using cexp directly)
<taylanub>ah, OK
<mark_weaver>we needed optimization before so that sin/cos would be converted into cexp.
<taylanub>Still getting -0.0 from cimag(cexp(conj(0.0)))
<taylanub>(with -O0)
<mark_weaver>gah, sorry, I'm making mistakes again.
<mark_weaver>let me cook up a proper test program for you to try.. bbiab
<taylanub>OK, I'm at work for another ~30 minutes (and don't need to catch a bus today), otherwise we can continue tomorrow
<mark_weaver>taylanub: can you try compiling this with -O0? http://paste.lisp.org/+31RZ
<mark_weaver>or better yet, this one: http://paste.lisp.org/+31S0
<mark_weaver>gcc -O0 -o test test.c -lm
<taylanub>cexp (0.000000 + -0.000000 i) => 1.000000 + 0.000000 i
<mark_weaver>there you go!
<mark_weaver>it's a bug in cexp on MacOS
<mark_weaver>thanks!
<taylanub>my pleasure :-)
<mark_weaver>C11 section G.6.3.1 states that cexp(conj(z)) = conj(cexp(z)) and that cexp(0+i0) = 1+i0. Since conj(0+i0) = 0-i0, it follows that cexp(0-i0) = conj(cexp(0+i0)), which is 1-i0.
<developernotes>Is this (https://www.gnu.org/software/guile/manual/html_node/Guile-Modules.html#Guile-Modules) to best route to learning/reading about the various functions available within the ice-9 module in guile? Is there another recommendation?
*mark_weaver goes afk
<taylanub>developernotes: I think the "API Reference" section also references some ice-9 modules
<developernotes>sorry, the best, not to best
<developernotes>taylanub ok, thanks
<mark_weaver>yeah, the ice-9 modules are documented in both of those chapters.
<mark_weaver>(and some are not documented at all)
<developernotes>Are those two chapters the recommended way to approach it, or reading the source?
<taylanub>developernotes: a glance at the $guile_source/module/ice-9/ directory will list you all the ice-9 modules
<taylanub>and the ones not in the manual aren't documented at all I suppose, dunno
<developernotes>taylanub gotcha - thanks
<ArneBab>mark_weaver: will you report the OSX bug or work around it? (or both?) Is it only OSX or other BSDs, too?
<mark_weaver>ArneBab: neither. it's not really something that we can work around sanely, and it's also probably not that important for most people. I suggest that someone who cares about MacOS X should report it to Apple.
<mark_weaver>I think this is only on OSX. I've not heard any similar report for BSD.
<taylanub>I was about to ask too how to best proceed. Maybe I can report the bug from my employer's Apple developer account, though it's iOS-only I think.
<taylanub>on OpenBSD 5.3 I didn't have this issue
<taylanub>well I don't remember what GCC versions I used, I think I only ever used the OpenBSD-patched GCC 4.2
<mark_weaver>it may be that clang doesn't convert sin/cos calls into a single cexp call, so you might not notice the problem there.
<mark_weaver>the latest test program I gave you is the best way to test for it (making sure to compile with -O0)
<ArneBab>there is already proper test-code, so I would grieve to see this disappear.
<mark_weaver>it would be interesting to try that test code on the BSD systems.
<ArneBab>I’ll ask in #freebsd
<ArneBab>open solaris does not have the bug.
<ArneBab>(I just ran the code on our institutes sun-cluster)
<mark_weaver>thanks!
<ArneBab>it just took a minute ☺
<ArneBab>(at least with GCC, that is)
<mark_weaver>I suspect the compiler doesn't matter, especially if you compile with -O0
<ArneBab>sun-compiler works, too
<ArneBab>icc (intel compiler) has the bug
<ArneBab>icc -O0 -o test test.c -lm
<ArneBab>cexp (0.000000 + 0.000000 i) => 1.000000 + 0.000000 i
<ArneBab>that’s the compiler we are expected to use on the universities high-performance clusters…
<mark_weaver>ArneBab: so that bug is in a different place. conj(0.0) didn't return (0.0-0.0i)
<ArneBab>oh…
<ArneBab>yes
<mark_weaver>(maybe cexp is broken also, dunno)
<ArneBab>replicated on the high-performance cluster.
<ArneBab>so this is not that much of a corner-case ☹
<ArneBab>(and it would be nice to have this documented somewhere - is there a proper place for this in the guile docs?)
<mark_weaver>document what?
<ArneBab>that certain complex number libraries behave in a non-standard way.
<ArneBab>so people do stumble over this again
<ArneBab>bbiab
<mark_weaver>well, this sounds like documenting that some systems have bugs. seems like a strange thing to document.
<mark_weaver>I'm not sure where that would go.
<ArneBab>re
<ArneBab>hm, ok
<ArneBab>do you have a link to the standard at hand? In that case I could just write a short blog post about it.
<ArneBab>that would then at least provide a googleable reference ☺
<mark_weaver>ArneBab: here's the final draft of C11: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf
<mark_weaver>the final standard itself is behind a paywall.
<ArneBab>thanks - and gah…
<ArneBab>I don’t see anything in the standard about cexp (0 + -i0). It only says cexp(±0 + i0) returns 1 + i0.
<ArneBab>page 561
<mark_weaver>ArneBab: yes, and the first rule is that cexp(conj(z)) = conj(cexp(z))
<ArneBab>yes
<mark_weaver>conj(a+bi) = a-bi
<ArneBab>ah, yes, you’re right: The conj functions compute the complex conjugate of z, by reversing the sign of its
<ArneBab>imaginary part.
<mark_weaver>yep
<ArneBab>so conj is broken in icc?
<mark_weaver>looks like it
<ArneBab>I just doublechecked it. conj(1.0 + i0.0) is does not reverse the sign.
<mark_weaver>okay
<ArneBab>I’m writing a short note.
<mark_weaver>thanks!
<ArneBab>taylanub: can you give me your compiler version again (gcc --version)
<ArneBab>taylanub: and could you compile and run the code here? http://draketo.de/light/english/complex-numbers-compiler-libc-bugs-icc-osx-cexp-conj
<ArneBab>mark_weaver: note written: http://draketo.de/light/english/complex-numbers-compiler-libc-bugs-icc-osx-cexp-conj
<developernotes>should I be able to use #:rest in a standard define like this: http://pastie.org/9108884
<developernotes>I get a pattern match error, is there a better way to express that?
<mark_weaver>you need to use define* for that
<mark_weaver>if you use plain 'define', then the thing to do is (define (print format-value . args) ...)
<mark_weaver>that's the standard scheme way to specify 'rest' args.
<developernotes>mark_weaver ah, gotcha - thanks.
<mark_weaver>but actually you need to use 'apply' there.
<mark_weaver>(apply format ...) instead of (format ...)
<developernotes>mark_weaver with define* it appears to bind the args as a list
<mark_weaver>that's right
<developernotes>hence the need for apply?
<mark_weaver>yeah, the last argument to 'apply' must be a list, and the elements of that list are added to the end of the argument list.
<developernotes>awesome - gotcha - thank you
<mark_weaver>well, now that I look at the code, there are other problems as well. (format #t ...) outputs to the current-output-port. so why are you calling 'display' here? there's no need for it.
<developernotes>mark_weaver so is define with a . args the preferred style, rather than #:rest args?
<mark_weaver>oh, I don't know. it's a matter of taste I suppose. #:rest is probably more readable, but the '.' thing is more portable.
<developernotes>mark_weaver ah, good catch - I don't need the leading display
<developernotes>ok, good to know - thank you
<mark_weaver>for better or worse, there's a lot of diversity in the scheme community. many different dialects of scheme, many preferred styles, etc.
<mark_weaver>ArneBab: the proper place to record these bugs are probably in the relevant bug tracking systems.
<mark_weaver>*places
<mark_weaver>if the original report of this test failure in guile had been sent to bug-guile instead of guile-devel, then there would be a record of it in our bug tracking system as well.
<ArneBab>ah, yes
<ArneBab>mark_weaver: by the way: the draft to py2guile is almost finished. All that’s still missing are “creating new OOP systems” and a few summaries.
<ArneBab>and one shortcoming (duplication and overhead)
<mark_weaver>ArneBab: if you want a really good example of embedding new languages in scheme, see The Reasoned Schemer
<ArneBab>mark_weaver: that’s on my reading list
<ArneBab>but I did not yet get to it - the spanish lord of the rings should be first
<ArneBab>but it’s good to know that there’s a canonical source ☺
<mark_weaver>the spanish lord of the rings?
<ArneBab>(though I think that personal accounts are better for the article)
<ArneBab>the lord of the rings in spanish (translated)
<mark_weaver>ah, okay :)
<ArneBab>to get better at spanish ☺
<ArneBab>I can’t let my children get too much better at spanish than I am ☺
<davexunit>I've been meaning to buy the reasoned schemer. I wonder if mit press has it in their brick and mortar store.
<mark_weaver>davexunit: iirc, I bought my copy in that store
<davexunit>cool, I got my copy of the little schemer there. next time I'm in kendall square I'll stop by and see.
<mark_weaver>ArneBab: have you read http://mumble.net/~campbell/scheme/foof-loop.txt ?
<mark_weaver>I think we should probably import that into core guile, but it should work out-of-the-box anyway.
<davexunit>I see foof-loop every now and again, but I haven't yet taken the time to read how this.
<mark_weaver>initially I used SRFI-42 for this sort of thing, but I've come to believe that foof-loop is probably better for most things.
<davexunit>I use srfi-42 a lot so I should look into this.
<mark_weaver>and I like that 'foof-loop' generates purely functional code, as opposed to SRFI-42 which generates imperative code that mutates loop variables, etc.
<davexunit>oh that's a big advantage.
<ArneBab>mark_weaver: I read parts of foof-loop
<ArneBab>but I prefer srfi-42
<ArneBab>(as user)
<zacts>do any of you know what frons is?
<ArneBab>mutating loop variables does not sound that nice, though
<ArneBab>I did not write a lot in foof-loop
<ArneBab>davexunit: to get foof-loop working, I had to setup guildhall: https://github.com/ijp/guildhall/wiki/Getting-Started
<ArneBab>mark_weaver: having guildhall in guile by default would be pretty niice
<ArneBab>nice
<mark_weaver>yeah, we need to get guildhall.gnu.org set up (or whatever the host name is)
<mark_weaver>but also, I think it would be good to get foof-loop into core guile
<ArneBab>as (use-module (ice-9 foof-loop))?
<ijp>mark_weaver: I dunno, I'm no fan of the way foof-loop gets extended
<ArneBab>what I thought strange about foof-loop were things like (loop (for element (in-list …)))
<ijp>I tolerate it, because I have to do it so little
<mark_weaver>ijp: hmm, I was looking at it the other day and thinking about making a version based on 'ck' with a better interface for that.
<ArneBab>that `in-list` instead of just `in` (and figuring out the type in the loop) looks overly verbose.
<ijp>figuring out the type is problematic
<ArneBab>as if you have to take a lot of time just learning the API to foof-loop
<ijp>in guile, we could use goops, but I'm not so keen on it
<ArneBab>ijp: as I see you right now: would you like to write a paragraph on implementing OOP systems in guile?
<ijp>nope
<ArneBab>ok - couldn’t hurt to ask ☺
<mark_weaver>ArneBab: not sure why you'd ask ijp about that; I get the impression he's not a big fan of OOP in general.
<mark_weaver>(nor am I)
<ijp>mark_weaver: I'm not actually against it
<ArneBab>mark_weaver: because he told me that he has a clear idea how he would like an OOP system to be, so I guessed he had tried his hand at a few
<ijp>I just have very odd views about ad hoc polymorphism
<mark_weaver>Haskell's take on OOP is much more reasonable than the OOP that most people know.
<ijp>I have it solved in my mind only for static OOP languages
<ijp>haskell almost has it right for static functional languages, once someone figures out local instances
<mark_weaver>is it unknown_lamer who knows a lot about CLOS and GOOPS? I forget.
<unknown_lamer>I am a wizard
<mark_weaver>:)
<mark_weaver>ArneBab: so maybe you should ask unknown_lamer :)
<mark_weaver>although I'm not quite clear on what you're looking for.
<unknown_lamer>CLOS hurts me, because it is so great but so fundamentally flawed. This is what I get for learning SML.
<ArneBab>mark_weaver: I’m just looking for a personal note from someone who used the freedom of hacking on OOP
<unknown_lamer>but like many things, Worse Is Better (tm) and when CLOS is the "worse" ... I'll take it
<daviid>CLOS is the best, imo :)
<daviid>and by far
<ArneBab>unknown_lamer: would you like to write a paragraph on implementing new OOP systems in Guile Scheme - as guest author in my python-to-guile article?
<unknown_lamer>ijp: haskell OO you say?
<ArneBab> http://draketo.de/proj/py2guile/#sec-6-2
<ijp>unknown_lamer: typeclasses
<ijp>if it weren't so tedious, I would do interface passing
<unknown_lamer>I need to look at what happened to Qi-CLOS and Shen
<unknown_lamer>ijp: aha!
<ijp>which is what happens in haskell under-the-hood
<mark_weaver>guile-gnome uses the flexibility of GOOPS's MOP to make gobject classes and objects available to GOOPS in a seamless manner.
<unknown_lamer>I need to get the pierce type book
<ijp>unknown_lamer: he has two now
<unknown_lamer>god damnit
<unknown_lamer>I need to implement dependent subtyping or some kind of fancier refinement typing in domtool, but ... subtyping is hard
<unknown_lamer>let's go hack some lisp instead
<ArneBab>unknown_lamer: Since I don’t yet have the experience of taking Guile far beyond Python, I thought it would be pretty neat to have guest authors who write a short paragraph or so about their experience
<ijp>TAPL, and "advanced topics in TAPL"
<mark_weaver>I wonder if it would be possible to use the power of scheme to make interface passing less onerous.
<ijp>mark_weaver: the real problem comes when you accidentally pass in the wrong one
<unknown_lamer>ArneBab: using GOOPS, you can define your own object systems!
<unknown_lamer>who wouldn
<unknown_lamer>t want to change the fundamental behavior of the language ;)
<ArneBab>unknown_lamer: do you have a project in which you did that? (an example)
<ijp>quotemstr on #emacs basically proposed a similar thing for emacs recently, in place of EIEIO
<unknown_lamer>ArneBab: http://unknownlamer.org/code/guile-web.html
<ArneBab>ijp: if guile-emacs finally gets into production state with this years GSoC, that could be very close ☺
<ijp>mark_weaver: you can use parameters to hide some of it, I think
<unknown_lamer>but I sort of got distracted by CLOS and paying work using CLOS, so http://unknownlamer.org/darcsweb/browse?r=ucw-core_clinton;a=summary and http://git.hcoop.net/?p=clinton/lisp-on-lines.git;a=summary are better examples
<mark_weaver>ijp: parameters are very problematic, and I don't see how that would work. what is you need to pass in more than one interface?
<mark_weaver>s/what is/what if/
<unknown_lamer>ArneBab: http://unknownlamer.org/darcsweb/browse?r=guile-web;a=headblob;f=/src/serialize.scm this is some grade A GOOPS abuse
<ijp>well, I'd envision one parameter per interface, with the parameter containing a mapping from types to implementations
<ijp>but the whole thing ends up being not very nice
<ArneBab>unknown_lamer: can you write in two or three sentences what you like best about it?
<ArneBab>(looking at it serialize right now)
<ijp>this is why it remains something I think about, and not something I've implemented and am recommending
<mark_weaver>what if we had the racket feature where procedure calls (p a b c) are expanded as a macro like ($app p a b c). would that make it doable?
<unknown_lamer>ArneBab: multimethods? the meta-object protocol allowing you to mold the object system to your needs?
<mark_weaver>it wouldn't be too hard to add that feature to guile. I just haven't gotten around to it.
<unknown_lamer>can't really think of anything else (working for the man right now)
<ijp>actually, I wanted that a while back, but I've completely forgotten my usecase
<ArneBab>unknown_lamer: I mean something which you’d be happy to be quoted on ☺
<ijp>'unknown_lamer
<unknown_lamer>heh
<unknown_lamer>ArneBab: perhaps later I can come up with a soundbite, but work is sucking up my brain cycles atm
<ArneBab>unknown_lamer: ok - thanks!
<george2>Why might I be getting this #<unspecified> in my (write(eval))? http://lpaste.net/103164 https://github.com/george2/csci400-scheme/blob/master/main.scm
<george2>Is it trying to parse the newline in the input or something?
<mark_weaver>george2: it's because 'write' returns #<unspecified>
<george2>ahh, that makes sense
<george2>Is there a way to discard that output?
<mark_weaver>Guile's REPL contains a hack: if the return value is *unspecified*, then it doesn't print anything.
<mark_weaver>you can use 'unspecified?' to check for it. not generally recommended to use that predicate, but for a REPL it's sensible.
<george2>ok.
<ijp>it only does it if you return exactly one value, I think
<mark_weaver>ah, that too. Guile's REPL can accept multiple return values, and prints them all.
<ijp>hmm, apparently I'm wrong
<ijp>(values (cond (#f #f))(cond(#f #f)))
<ijp>prints nothing
<ijp>and (values (cond (#f #f)) 1 (cond(#f #f))) prints only 1
<mark_weaver>for example (floor/ 5 3) returns two values: 1 and 2.
<mark_weaver>interesting. that sounds suboptimal to me. we should probably fix it.
<ArneBab>unknown_lamer: US healthcare only requires folks above 30 to have an insurance???
<unknown_lamer>huh
<unknown_lamer>oh, probably something I wrote ages ago
<unknown_lamer>ArneBab: no, people under 30 can get useless catastrophic insurance
<ArneBab>oh…
<ArneBab>unknown_lamer: I stumbled over the part which “I am likely not interested in” ☺
<unknown_lamer>the new healthcare law is great, now everyone is mad at me for not being able to afford insurance even with subsidies, instead of taking pity on me
<unknown_lamer>like "stop eating! then you can afford it!"
<ArneBab>oh…
<unknown_lamer>I just want some communist socialized healthcare dangit, like a civilized country
<unknown_lamer>but, meh, politics
<ArneBab>so you don’t get it money from the state if you can’t pay for healthcare?
<unknown_lamer>you do, but in my state there is only one insurer on the exchange and they raised prices by more than the subsidy, at least for me
<unknown_lamer>I hear it has worked out less horribly in other areas
<ArneBab>ouch ☹
<taylanub>ArneBab: Compiler is GCC 4.8.2 from MacPorts. I can test your code tomorrow at work, don't have OS X myself (neither OpenBSD anymore).
<taylanub>ArneBab: By the way thanks for putting up that info on your web page!
<taylanub>ArneBab: You might want to add that compiler optimizations can result in cexp() calls where there are none (which is how this bug surfaced in our case).
<mark_weaver>cexp(z) = e^z = e^(a+bi) = e^a * e^(bi) = e^a * (cos(b) + i*sin(b))
<mark_weaver>for real 'b', e^(bi) is a point on the unit circle on the complex plane.
<ArneBab>gladly!
<mark_weaver>so cexp(bi) can be used to compute cos(b) and sin(b) simultaneously, and probably faster than calling 'sin' and 'cos' separately.
<ArneBab>mark_weaver: that’s one of the reasons why complex numbers are so important in physics
<mark_weaver>complex exponentials are very nice. if you know a little about them, then you'll never have to remember all of those tedious formulas for sin and cos of sums and similar things. you can figure them all out from basic principles rather easily.
<mark_weaver>complex numbers have much nicer properties than "real" numbers.
<mark_weaver>ArneBab: yep
<ArneBab>yep ☺
<ArneBab>(in physics they are being used for everything wavy - and almost everything which moves is to some degree wavy ☺)
<ArneBab>and you can trivially differenciate an exponential ☺
<mark_weaver>yeah, complex exponentials are generally much easier to work with than sin and cos.
<mark_weaver>wingo: I'm trying to adapt civodul's (system base types) for master. can you briefly summarize the changes in representation of procedures/programs in master, compared with stable-2.0 ?
<mark_weaver>(working on merging stable-2.0 into master)
<wingo>mark_weaver: it's the same in master as 2.0, i think
*wingo brb
<mark_weaver>okay
<mark_weaver>ah, the tag for programs changed from 79 to 69
<mark_weaver>(the tc7)
<mark_weaver>and there seems to be no more objcode or vm types
<mark_weaver>wingo_: are 'objcode' and 'vm' types no more, or are they just represented in a different way now?
<wingo_>mark_weaver: they are no more
<mark_weaver>okay, thanks
***wingo_ is now known as wingo
<mark_weaver>wingo: are weak sets available to scheme?
<wingo>mark_weaver: no
<mark_weaver>okay
<zacts>mark_weaver: do you know what frons is?
<mark_weaver>zacts: no
<mark_weaver>wingo: in the tag word of vectors/weak-vectors, is there anything special stored in bit 7 ? it seems maybe there used to be.
<zacts>mark_weaver: mind if I send you a link?
<wingo>mark_weaver: i don't think so, no
<mark_weaver>zacts: sure
<mark_weaver>wingo: thanks
<wingo>the tc7s thing is not a thing any more iirc
<wingo>tc7s versus tc7
<mark_weaver>in stable-2.0, civodul went out of his way to avoid checking bit 7. not sure if that's still needed.
<mark_weaver>(when looking for vectors, I mean)
<zacts> http://projects.csail.mit.edu/wiki/pub/JoeNear/FernMonad/frons.pdf
<zacts>and - http://www.youtube.com/watch?v=IHP7P_HlcBk
<mark_weaver>zacts: thanks, will check it out later. (busy now merging)
<zacts>oh sorry! :-)
<mark_weaver>zacts: no apology needed; thanks for the link!
<zacts>I'm trying to find the point in that lecture where he talks about frons, but it sounds really cool.
<zacts>frons is like a new abstraction for cons
<zacts>it's either the 2nd or 3rd item of the lecture
<george2>Can I import local files?
<george2>something like #include "myfile.h" in C?
<zacts>(load "myfile.scm") ?
<george2>ah, cool :)
<ijp>or include, or use-modules...
<wingo>mark_weaver: yeah it used to be that weak vectors and vectors shared an impl, and so as a hack often shared a type predicate that just checked 6 bits instead of 7
<wingo>but now weak vectors are a separate thing, and the tc7 tags don't have anything to do with each other
<mark_weaver>wingo: okay, thanks!
<george2>why so many words for the same thing? are they each slightly different?
<ijp>george2: load, loads at runtime. include, includes at expansion time.
<ijp>use-modules is like include, but more useful
<george2>how so?
<mark_weaver>use-modules loads a separate module (if not already loaded) in its own namespace, and imports whatever is exported from it. that's the usual way of breaking programs into multiple modules.
<mark_weaver>'include' actually splices the contents of the named file directly in place of the 'include' form, even if it's within a local scope.
<ijp>you refer to a module by a module identifier, rather than an absolute path. It will only be loaded at most once (I think). Each module is in a different namespace. You can selectively include/exclude/rename bindings
<mark_weaver>'load' is a normal procedure. (well, it mostly acts like one anyway)
<george2>ok
<mark_weaver>wingo: I just noticed that 'object->string' is broken for weak vectors.
<mark_weaver>(in master, not in stable-2.0)
<wingo>mark_weaver: oops :)
<wingo>you on it or should i?
<mark_weaver>wingo: if you're willing, please fix! :)
<wingo>sure :)
<wingo>will be tomorrow tho
<mark_weaver>thanks!
<mark_weaver>mmm, maybe I'll do it then.
<mark_weaver>(it's an issue for this merge)
<mark_weaver>it's probably an easy fix, so not a problem.
<zacts>mark_weaver: ok, the frons is at 17 minutes and 20 seconds of the lecture
<zacts>the guy steele jr. cool ideas lecture
<mark_weaver>zacts: thanks!