01:53:47 -!- alms_ [~alms_@146-115-42-237.c3-0.bkl-ubr1.sbo-bkl.ma.cable.rcn.com] has quit [Quit: alms_] 01:54:51 alms_ [~alms_@146-115-42-237.c3-0.bkl-ubr1.sbo-bkl.ma.cable.rcn.com] has joined #ccl 01:58:25 -!- alms_ [~alms_@146-115-42-237.c3-0.bkl-ubr1.sbo-bkl.ma.cable.rcn.com] has quit [Client Quit] 01:58:53 alms_ [~alms_@146-115-42-237.c3-0.bkl-ubr1.sbo-bkl.ma.cable.rcn.com] has joined #ccl 02:09:53 -!- leo2007 [~leo@cpc1-cmbg13-0-0-cust596.5-4.cable.virginmedia.com] has quit [Ping timeout: 240 seconds] 03:14:42 -!- baggles [~bill@88-106-155-41.dynamic.dsl.as9105.com] has quit [Ping timeout: 250 seconds] 04:06:24 bfulgham_ [~brent@adsl-69-234-136-108.dsl.irvnca.pacbell.net] has joined #ccl 05:32:29 -!- roffe [~roffe@adsl-149-197.romerikebb.no] has quit [Read error: Connection reset by peer] 05:32:45 roffe [~roffe@adsl-149-197.romerikebb.no] has joined #ccl 06:29:21 -!- roffe [~roffe@adsl-149-197.romerikebb.no] has quit [Remote host closed the connection] 06:30:25 roffe [~roffe@adsl-149-197.romerikebb.no] has joined #ccl 08:11:20 e-user [~akahl@nat/nokia/x-eqaktoqhdrgxzoyr] has joined #ccl 09:29:02 jdz [~jdz@193.206.22.97] has joined #ccl 09:32:20 tfb [~tfb@94.197.38.159.threembb.co.uk] has joined #ccl 10:27:27 -!- roffe [~roffe@adsl-149-197.romerikebb.no] has quit [Remote host closed the connection] 10:28:07 roffe [~roffe@adsl-149-197.romerikebb.no] has joined #ccl 11:15:17 leo2007 [~leo@cpc1-cmbg13-0-0-cust596.5-4.cable.virginmedia.com] has joined #ccl 12:13:10 christoph_debian [~christoph@DSL01.212.114.250.148.ip-pool.NEFkom.net] has joined #ccl 12:46:28 -!- roffe [~roffe@adsl-149-197.romerikebb.no] has quit [Ping timeout: 265 seconds] 12:49:09 -!- tfb [~tfb@94.197.38.159.threembb.co.uk] has quit [Quit: sleeping] 13:13:22 -!- sellout [~greg@gw3.tacwap.org] has quit [Quit: sellout] 13:21:06 roffe [~roffe@ti0165a340-dhcp0368.bb.online.no] has joined #ccl 13:29:32 sellout [~greg@64.134.66.221] has joined #ccl 13:34:07 -!- sellout [~greg@64.134.66.221] has quit [Ping timeout: 255 seconds] 13:54:56 tfb [~tfb@92.41.243.83.sub.mbb.three.co.uk] has joined #ccl 15:39:16 sellout [~greg@64.134.66.221] has joined #ccl 15:41:38 -!- bfulgham_ [~brent@adsl-69-234-136-108.dsl.irvnca.pacbell.net] has quit [Quit: bfulgham_] 15:51:41 -!- sellout [~greg@64.134.66.221] has quit [Quit: sellout] 16:06:04 sellout [~greg@c-24-61-13-161.hsd1.ma.comcast.net] has joined #ccl 16:44:15 anRch [~markmilli@64.134.96.212] has joined #ccl 16:58:21 -!- jdz [~jdz@193.206.22.97] has quit [Quit: Leaving] 17:05:07 -!- e-user [~akahl@nat/nokia/x-eqaktoqhdrgxzoyr] has quit [Quit: Leaving.] 18:02:35 -!- anRch [~markmilli@64.134.96.212] has quit [Quit: anRch] 18:29:24 -!- leo2007 [~leo@cpc1-cmbg13-0-0-cust596.5-4.cable.virginmedia.com] has quit [Quit: rcirc on GNU Emacs 23.2.91.1] 18:42:31 -!- tfb [~tfb@92.41.243.83.sub.mbb.three.co.uk] has quit [Ping timeout: 246 seconds] 19:44:03 is there an efficient way to get a chunk of, say, fixnum-many bits (or 32 bits, or whatever is convenient) from a bit-array? 19:57:32 clop2: Sort of like LDB for a bit-vector? I don't think so, though it might not be too hard to hack up a little lap function to do something like that. Or you could consider using integers instead of bit vectors. 19:57:59 rme, ok thanks! 20:00:35 subseq tries to do a byte at a time when :start is suitable, but it conses, of course. 20:27:50 tmh [6348b02c@pdpc/supporter/sustaining/tmh] has joined #ccl 20:27:58 Hello! 20:59:52 is it possible to imagine functions that efficiently convert bignums to 32-bit arrays and vice-versa? 21:02:34 clop2: you can use ccl:uvref for that. For example, (uvref (1+ most-positive-fixnum) 1) => 268435456 21:03:45 right, I think I remember that the bignum representation is as a uvector of 32-bit data words in little-endian order... 21:03:57 that's correct 21:04:12 and that uvref is an honest-to-goodness 32-bit simple-vector? 21:05:26 Well, uvref knows how to reference elements of uvectors---it dispatches on the type code of the uvector to know how to retrieve the appropriate element. 21:05:50 ah hrmn 21:06:18 so if i had a simple-vector of (unsigned-byte 32), to make a bignum from it I could presumably tack on some kind of header? 21:07:08 -!- tmh [6348b02c@pdpc/supporter/sustaining/tmh] has quit [Ping timeout: 265 seconds] 21:07:29 er, I see, uvref is doing something akin to bignum[slice] 21:12:07 I don't know that you want to be messing around bashing uvector headers. 21:13:16 yeah I don't know either. :) 21:14:58 we're just some performance issues with a function and trying to figure out a better approach... we could probably use uvref/uvset to create fast bignum->array and array->bignum conversions 21:16:16 and that probably will be fast enough without getting us into header mangling 21:18:27 That would be safe, and probably sufficiently fast, as you say. If not, we could probably rig up something using ccl::%copy-ivector-to-ivector. 21:21:20 hrmn, yeah that's sufficiently scary :) 21:21:33 i think i'll just try it with the uvset/uvref 21:23:01 don't forget that you can use uvref with setf. 21:26:57 oh neat 21:35:20 There are lots of constraints on the contents of a bignum (at least those that're arguments to math functions.) 21:38:30 aah, is it not a good idea to just be setting their contents with a bunch of stuff, then? 21:43:03 And then passing them to a math function ? No. 21:44:07 What is the problem you're having that makes you ask about this ? 22:02:38 -!- sellout [~greg@c-24-61-13-161.hsd1.ma.comcast.net] has quit [Read error: Connection reset by peer] 22:11:02 oh, we are representing certain sets as bignums so that they can be unioned together with logior, etc 22:11:17 but then in other cases we represent them as arrays so that we can destructively update them 22:11:48 and just were thinking about a way to sort of merge existing bignums-style sets into arrays that are being destructively updated 22:12:29 this is all kind of preliminary so we probably do not need anything yet 22:12:55 i was mostly just interested in how efficiently this back-and-forth could be done 22:13:07 i think the uvref stuff is probably what we want 22:13:23 sellout [~greg@c-24-61-13-161.hsd1.ma.comcast.net] has joined #ccl 22:18:28 I take it bit-ior, etc. not fast enough? 22:29:39 anRch [~markmilli@64.134.65.73] has joined #ccl 22:37:10 i think the performance is just fine, but we start running out of memory... 22:37:17 apparently it's not okay to keep 90 GB of bignums floating around 22:37:18 who knew? 22:37:50 time to buy more RAM 22:38:02 that was my take 22:38:17 and was rejected without, i thought, proper consideration :) 22:38:30 oh well, i'm off -- we'll nail it down tomorrow 22:38:50 They've got to be selling 32GB ecc dimms at walmart by now. 22:39:32 maybe not ecc. 23:36:41 -!- anRch [~markmilli@64.134.65.73] has quit [Quit: anRch]