00:19:51 -!- homie [~levgue@xdsl-87-79-192-142.netcologne.de] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 00:37:22 edgar-rft [~user@HSI-KBW-078-043-123-191.hsi4.kabel-badenwuerttemberg.de] has joined #sbcl 00:54:22 -!- edgar-rft [~user@HSI-KBW-078-043-123-191.hsi4.kabel-badenwuerttemberg.de] has quit [Remote host closed the connection] 01:19:17 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 01:23:45 homie [~levgue@xdsl-87-79-192-142.netcologne.de] has joined #sbcl 01:33:41 edgar-rft [~user@HSI-KBW-078-043-123-191.hsi4.kabel-badenwuerttemberg.de] has joined #sbcl 02:04:30 Fare [~Fare@173-9-65-97-NewEngland.hfc.comcastbusiness.net] has joined #sbcl 02:12:09 -!- Fare [~Fare@173-9-65-97-NewEngland.hfc.comcastbusiness.net] has quit [Ping timeout: 246 seconds] 04:04:20 slyrus [~chatzilla@12.132.197.125] has joined #sbcl 04:04:41 Fare [~Fare@173-9-65-97-NewEngland.hfc.comcastbusiness.net] has joined #sbcl 04:19:32 -!- Fare [~Fare@173-9-65-97-NewEngland.hfc.comcastbusiness.net] has quit [Ping timeout: 246 seconds] 04:49:52 -!- edgar-rft [~user@HSI-KBW-078-043-123-191.hsi4.kabel-badenwuerttemberg.de] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 04:53:57 -!- stassats` [~stassats@wikipedia/stassats] has quit [Read error: Operation timed out] 06:17:41 -!- homie [~levgue@xdsl-87-79-192-142.netcologne.de] has quit [Read error: Connection reset by peer] 06:45:38 -!- Phoodus [~foo@wsip-68-107-217-139.ph.ph.cox.net] has quit [Ping timeout: 244 seconds] 06:53:52 angavrilov [~angavrilo@217.71.227.190] has joined #sbcl 07:56:09 sdemarre [~serge@91.176.163.235] has joined #sbcl 07:56:24 homie [~levgue@xdsl-78-35-184-138.netcologne.de] has joined #sbcl 09:05:27 Fare [~Fare@173-9-65-97-NewEngland.hfc.comcastbusiness.net] has joined #sbcl 09:16:15 nikodemus [~nikodemus@37-219-130-105.nat.bb.dnainternet.fi] has joined #sbcl 09:16:15 -!- ChanServ has set mode +o nikodemus 09:18:03 afternoon 10:12:41 nikodemus` [~nikodemus@178-55-142-42.bb.dnainternet.fi] has joined #sbcl 10:12:41 -!- nikodemus [~nikodemus@37-219-130-105.nat.bb.dnainternet.fi] has quit [Disconnected by services] 10:12:41 -!- ChanServ has set mode +o nikodemus` 10:23:53 -!- Fare [~Fare@173-9-65-97-NewEngland.hfc.comcastbusiness.net] has quit [Ping timeout: 246 seconds] 10:45:44 prxq [~mommer@mnhm-5f75c02e.pool.mediaWays.net] has joined #sbcl 10:47:44 attila_lendvai [~attila_le@188-143-65-33.pool.digikabel.hu] has joined #sbcl 10:47:44 -!- attila_lendvai [~attila_le@188-143-65-33.pool.digikabel.hu] has quit [Changing host] 10:47:44 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 13:08:53 hi 13:09:09 does anybody know a good tutorial for mod_lisp on apache? 13:16:52 Posterdati: ask #lisp. I believe the answer is to use hunchentoot. 13:19:44 pkhuong: yes, I'd like to use hunchentott 13:20:00 but I need dynamic contents and animation 13:20:31 I don't want to use dreamweaver or 3rd party commercial software I'd prefer to program all by myself 13:21:07 Posterdati: #lisp is a better channel for that type of discussion 13:21:14 ok 13:21:16 thanks 13:22:04 prxq: so, we're trying to see if there's a point to trying to generate all floats in [0, 1) 13:22:17 do you have practical use cases in mind? 13:39:51 if you use them to generate exponentially distributed rvs, then you can get a much better sampling of the tails 13:40:11 same thing for normally distributed rvs. 13:40:13 only one tail. 13:40:39 up to 8 sigmas now, up to i think 36 sigmas otherwise 13:40:51 yes, of course, only one tail 13:42:08 two tails for normal rvs 13:42:15 box mueller? 13:42:49 e.g. but you can also use the marsaglia one, where you'd need uniform rvs in (-1 1) 13:43:07 who else does it? 13:43:17 who else does what? 13:43:40 trying to generate all floats in [0, 1) instead of treating it as fixed point. 13:43:48 ah. matlab does 13:43:56 right, but apart from matlab? 13:44:06 i don't know anyone 13:44:13 gko [~gko@114-34-168-13.HINET-IP.hinet.net] has joined #sbcl 13:44:14 L'Ecuyer's random variate/simulation framework doesn't, for example. 13:46:46 that's an interesting data point. 13:47:31 can we make this conditional on the random-state object? 13:47:58 nikodemus`: i'm not sure I see (yet) a way to do that with decent perf. 13:48:18 pkhuong: i think keeping all bits random as much as possible is just trt. 13:48:21 ie. seed-random-state :high-quality-floats t 13:49:08 or provide sb-ext:random-float which comes with additional guaranteed? 13:49:16 tees, even 13:49:31 prxq: why? FP is an approximation anyway. 13:49:47 it gives a better approximation 13:49:54 Just adding to the uniform variate will destroy that information. 13:50:08 If it's that important, maybe it's the wrong approximation. 13:50:50 Seriously, generating denorms? What does one do with those? 13:54:49 nikodemus`: do you see a way to efficiently dispatch on whether the random-state holds a vector of random words or random doubles? 13:55:09 pkhuong: if you have already decided that this is worthless, that's your call. 13:55:33 c programmer's mentality 13:55:39 it's just the onus of having practical use cases is pretty important if no one else does it. 13:56:23 If it's 0-cost, that's another thing. 13:56:24 pkhuong: it's just a single branch, no? 13:56:42 nikodemus`: for ecah generated value. 13:57:26 prxq: actually, the main opposition I have to this is that it makes useful statistical variance reduction techniques useless. 13:58:06 pkhuong: that's interesing. Any pointers on that? 13:58:56 or rather, can you give an example for a technique that breaks 13:58:58 ? 13:59:03 There are two nifty basic tools that I find useful (and that depend on non-uniform variates being based on computing the inverse cdf) 13:59:35 first is antithetic variables. (- 1 x) will lose the extra bits. 13:59:43 true 14:00:19 second is common random streams. That'll still work if the underlying generator always does the extra random bit dance. 14:02:16 but not if we, e.g., generate both integer and float uniforms from the same state. Two simulations could get wildly out of sync if one asked for a random integer, and the other for a double value. 14:02:32 random-chunk has 6 branches now. one for update, one for arg-count-check, 4 for type-checkes. eliminating the type-checks and arg-count checks would make branching on the vector-type effectively free :) 14:02:40 k. 14:02:48 update is the slow path anyway ;) 14:03:42 nikodemus`: ok, what I was thinking is that we keep the same basic architecture of pumping randomness out of a bulk-updated vector. 14:05:34 The difference is that the vector can now be a vector of words or of doubles (singles as well, maybe?), and updating that vector can go through whatever dispatch mechanism we want. I'm partial to a normal function that's updated into a GF post-CLOS. 14:05:45 i'm about to head for a barbaque, so i'm not really following 14:05:49 pkhuong: have you observed the antithetic estimate to actually break? 14:05:55 but i'll check the logs :) 14:06:20 prxq: well, either it doesn't matter because the extra bits are useless, or it breaks. 14:06:39 in other news, my changes seem to have magically improved disassembly enough to break tests that tried to read it to check for full calls 14:07:12 because now ;;; [4] (FOO-INLINE X) appears in the output, making the test think it's a full call :) 14:07:17 heh 14:07:51 huangjs [~huangjs@190.8.100.83] has joined #sbcl 14:10:41 pkhuong: if all you ever do is that, then yes, id does not matter. 14:10:59 dtw [~dtw@pdpc/supporter/active/dtw] has joined #sbcl 14:24:43 pkhuong: most of the time, the additional bits are generated anyway in the current implementation. They are just discarded. In only once every 1000 calls, an additional 32 bit rn is generated, and then another only if that one is exactly zero, 14:25:33 so the cost for this is rather low. 14:26:58 denorms basically never happen. There is no explicit code involved in generating them in the patch i sent - they just happen (eventually) 14:27:50 -!- nikodemus` [~nikodemus@178-55-142-42.bb.dnainternet.fi] has quit [Quit: This computer has gone to sleep] 14:28:35 stassats [~stassats@wikipedia/stassats] has joined #sbcl 14:29:35 Mazingaro [~Tetsuja@host85-230-dynamic.17-87-r.retail.telecomitalia.it] has joined #sbcl 14:36:51 edgar-rft [~user@HSI-KBW-078-043-123-191.hsi4.kabel-badenwuerttemberg.de] has joined #sbcl 14:55:43 -!- sdemarre [~serge@91.176.163.235] has quit [Ping timeout: 276 seconds] 15:11:21 sdemarre [~serge@91.176.95.236] has joined #sbcl 15:31:39 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 265 seconds] 15:34:01 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 16:03:50 R generates doubles uniformly as [0,2^32)/2^32 in floats 16:16:21 btw, since C does not have integer-length, implementing this type of random float generation efficiently in C involves adding assembly to the source. 16:19:30 so maybe people do not write this kind of thing that often because it's a hassle without integer-length 16:19:51 Widely-supported gcc-ism though 16:31:38 C 4.656613057E-10 is 1/M1 M1 is set in a data statement in IGNLGI 16:31:38 C and is currently 2147483563. If M1 changes, change this also. 16:31:55 Octave, showcasing good programming practice since too long ago 16:47:49 -!- christoph_debian [~user@oteiza.siccegge.de] has quit [Remote host closed the connection] 16:48:04 stassats` [~stassats@wikipedia/stassats] has joined #sbcl 16:53:07 christoph_debian [~user@oteiza.siccegge.de] has joined #sbcl 17:28:03 -!- gko [~gko@114-34-168-13.HINET-IP.hinet.net] has quit [Ping timeout: 260 seconds] 17:32:27 attila_lendvai [~attila_le@188-143-65-33.pool.digikabel.hu] has joined #sbcl 17:32:27 -!- attila_lendvai [~attila_le@188-143-65-33.pool.digikabel.hu] has quit [Changing host] 17:32:27 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 17:40:08 ykm [~ykm@182.237.186.22] has joined #sbcl 17:40:59 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 17:53:27 -!- ykm [~ykm@182.237.186.22] has quit [Quit: Leaving.] 19:18:47 -!- homie [~levgue@xdsl-78-35-184-138.netcologne.de] has quit [Ping timeout: 245 seconds] 19:25:34 homie [~levgue@xdsl-78-35-129-51.netcologne.de] has joined #sbcl 20:01:31 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 20:06:27 Phoodus [~foo@ip72-223-116-248.ph.ph.cox.net] has joined #sbcl 20:17:54 stassats [~stassats@wikipedia/stassats] has joined #sbcl 20:24:08 -!- sdemarre [~serge@91.176.95.236] has quit [Ping timeout: 246 seconds] 20:40:12 Guest17867 [tunes@nat/google/x-koppdrfkmaqznxfy] has joined #sbcl 20:40:34 -!- Guest17867 is now known as FareWell 20:40:40 -!- FareWell is now known as FareTower 20:48:47 -!- Phoodus [~foo@ip72-223-116-248.ph.ph.cox.net] has quit [Ping timeout: 245 seconds] 20:50:37 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 276 seconds] 20:52:28 stassats [~stassats@wikipedia/stassats] has joined #sbcl 21:08:35 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 246 seconds] 21:09:52 stassats [~stassats@wikipedia/stassats] has joined #sbcl 21:10:38 argh... slime deadlock again. 21:12:10 slyrus: is it the helmut regression? 21:12:20 no, I don't think so 21:12:53 "the helmut regression" sounds like a good name for a band or movie though 21:15:21 hahaha 21:25:07 OK, I'm having those nasty stack overflows in UPDATE-CLASS again. 21:26:00 Considering how the overflow seems to move when I tweak the code, it might be some not-infinite-but-still-growing-too-large analysis of some kind. 21:26:23 which makes it all the harder to isolate. 21:27:03 I'm leaning towards opening a bug with just the repeated pattern of the stack trace. 21:27:11 Maybe that'll inspire a sb-pcl hacker. 22:27:37 -!- prxq [~mommer@mnhm-5f75c02e.pool.mediaWays.net] has quit [Quit: Leaving] 22:52:29 https://bugs.launchpad.net/sbcl/+bug/1001799 22:53:13 FareTower: where's the test-case? 22:54:08 Haven't been able to isolate a small one from .9Mloc of Lisp code yet. 22:55:01 our application code isn't modular at all and it builds upon several layers of macros before you reach plain CLOS calls. 22:56:18 Hum. I realize I might have given more of the stack trace. 23:01:45 ok, attached a full cycle of the infinite loop (caught by finite stack) 23:05:14 -!- FareTower [tunes@nat/google/x-koppdrfkmaqznxfy] has quit [Quit: Leaving] 23:09:33 Fare [fare@nat/google/x-oqkpzjyzxqiemvjd] has joined #sbcl 23:21:23 an obvious creation of two mutually recursive classes isn't enough to trigger the bug. 23:21:47 reproducing it possibly involves delayed finalization or something. 23:24:38 OK, can reproduce 23:24:54 that's good 23:24:55 if I load my example file without compiling it, that delays the finalization 23:30:31 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 276 seconds]