| 01:24.12 | *** join/#brlcad dtidrow (n=dtidrow@c-69-255-182-248.hsd1.va.comcast.net) |
| 02:42.20 | *** join/#brlcad IriX64 (n=mariodot@bas2-sudbury98-1177879183.dsl.bell.ca) |
| 02:44.44 | IriX64 | set \=/ doesn't cut it :) |
| 02:46.44 | IriX64 | ideas, raspberries, anything at all :) |
| 02:50.33 | thing0 | umm |
| 02:50.35 | thing0 | no idea |
| 02:50.37 | thing0 | ;P |
| 02:51.13 | IriX64 | :) |
| 02:55.14 | IriX64 | http://www3.sympatico.ca/mario.dulisse2/1024.png |
| 02:55.21 | IriX64 | incoming :) |
| 02:56.17 | IriX64 | frame buffer? frame buffer? that's not a frame buffer. now *that's a frame buffer (shades of crocodile dundee:)) |
| 02:59.52 | IriX64 | http://rafb.net/p/f66j4y13.html <--- still getting this though when I try to attach to X |
| 03:03.14 | IriX64 | http://rafb.net/p/uQAosD65.html <-- there's the dump if you want it |
| 03:04.50 | thing0 | afk |
| 03:04.51 | thing0 | cya |
| 03:05.06 | *** part/#brlcad thingAWAY (n=ric@124-168-109-27.dyn.iinet.net.au) |
| 04:04.11 | *** join/#brlcad thing0 (n=ric@124-168-109-27.dyn.iinet.net.au) |
| 04:16.59 | *** join/#brlcad dtidrow (n=dtidrow@c-69-255-182-248.hsd1.va.comcast.net) |
| 04:31.00 | *** join/#brlcad thing0 (n=ric@124-168-109-27.dyn.iinet.net.au) |
| 05:30.14 | *** join/#brlcad Laniakea (i=clock@217-162-204-120.dclient.hispeed.ch) |
| 06:21.48 | *** join/#brlcad IriX64 (n=mariodot@bas2-sudbury98-1177879183.dsl.bell.ca) |
| 06:22.20 | IriX64 | http://rafb.net/p/tkZi4B77.html <--- i coerced the build to cough this lung cookie up too, you interested? |
| 06:23.57 | IriX64 | thank God for -Wl,-allow-multiple-definition ;) |
| 06:26.52 | IriX64 | http://rafb.net/p/8dpmxK32.html <--- see, I'll keep coercing the build, if anything interesting pops up ill pastebin it |
| 06:27.43 | brlcad | please don't -- if you coerce it, it's no longer interesting |
| 06:27.59 | IriX64 | I'll tickle it instead |
| 06:28.34 | IriX64 | cmon thats blatant |
| 06:28.36 | brlcad | do whatever you like with it, just don't trail the noise into here via pastebins of random issues |
| 06:28.47 | IriX64 | ok ok |
| 07:05.44 | IriX64 | http://www3.sympatico.ca/mario.dulisse2/jove.png and issues.png is what i get with a coereced build ;) |
| 07:12.59 | *** join/#brlcad b0ef (n=b0ef@062016141081.customer.alfanett.no) |
| 07:24.14 | *** join/#brlcad b0ef (n=b0ef@062016141081.customer.alfanett.no) |
| 07:30.57 | *** join/#brlcad Laniakea (n=clock@zux221-122-143.adsl.green.ch) |
| 07:53.48 | *** join/#brlcad Laniakea (n=clock@zux221-122-143.adsl.green.ch) |
| 08:36.34 | *** join/#brlcad Elperion (n=Bary@p54877F0D.dip.t-dialin.net) |
| 08:42.45 | *** join/#brlcad Laniakea_ (n=clock@zux221-122-143.adsl.green.ch) |
| 09:15.16 | *** join/#brlcad elite01 (n=elite01@dslb-088-070-031-147.pools.arcor-ip.net) |
| 09:42.37 | *** join/#brlcad docelic (n=docelic@ms52-2-gprs01.net.vip.hr) |
| 10:30.13 | *** join/#brlcad Elperion (n=Bary@p54877F0D.dip.t-dialin.net) |
| 11:49.49 | *** join/#brlcad cad98 (n=be31d7da@bz.bzflag.bz) |
| 13:06.47 | *** join/#brlcad docelic (n=docelic@212.15.176.222) |
| 13:10.40 | *** join/#brlcad dtidrow (n=dtidrow@c-69-255-182-248.hsd1.va.comcast.net) |
| 13:38.26 | *** join/#brlcad poolio (n=poolio@c-69-251-3-107.hsd1.md.comcast.net) |
| 13:42.06 | *** join/#brlcad IriX64 (n=IriX64@bas2-sudbury98-1177878614.dsl.bell.ca) |
| 14:06.46 | poolio | brlcad: I'm working on mutation, and currently all the stuff is going to be completely hard-coded in. Is there any sort of routine where I can say function(rt_db_internal) and somehow iterate through every changeable value? |
| 14:07.22 | poolio | I guess the other option would be to just have a switch statement and then have a function pointer for each type of object, I was just wondering if something like that had been done before |
| 14:29.20 | brlcad | not sure what you mean by iterate through every changeable value |
| 14:30.29 | brlcad | there is already a table (rt_functab) that has function pointers to various functionality, though whether that's useful is another matter of course.. not sure what you're getting at :) |
| 14:31.45 | poolio | W |
| 14:31.45 | poolio | W|10:31| <@ brlcad> there is already a table (rt_functab) that has function pointers to various functionality, though whether that's useful is another matter of course.. not sure what you' |
| 14:31.49 | poolio | ah oops |
| 14:31.51 | poolio | sorry |
| 14:34.19 | poolio | brlcad: Well what I meant was like I need to be able to change every specific value for each shape. So currently I have it setup to test which shape it is, and then depending on what shape, it can change certain specific values specific to that shape. So I was wondering if there was a way to generalize the way I go about this, I currently hard code in say if(sphere){rand = rand()%num_variables_can_be_changed_in_sphere; mutate(rand);} |
| 14:34.40 | poolio | Is there a way I could have something like x = num_specific_vars(shape)? |
| 14:40.54 | brlcad | poolio: the closest you could probably do is work with the tcl string representation of the primitive but even then you need to know what the values mean |
| 14:41.08 | brlcad | you're still only going to support a limited set of primitives |
| 14:41.55 | brlcad | you wouldn't likely ever create a DSP terrain object, for example, nor want to know how to genericly specify one |
| 14:43.02 | brlcad | your idea of having a switch statement and then functions for each primitive type that beset understands is probably the best approach |
| 14:44.24 | dtidrow | http://www.buy.com/retail/product.asp?sku=202930159&adid=17051&dcaid=17051 - nice! |
| 14:47.18 | brlcad | very nice |
| 14:47.33 | Laniakea_ | ``Erik: emulation? |
| 14:48.07 | brlcad | Laniakea_: did that compilation problem ever get sorted out? |
| 14:49.09 | Laniakea_ | brlcad: no Erik said he has to try out OpenBSD emulated |
| 14:49.18 | brlcad | ah, ok |
| 14:49.26 | Laniakea_ | brlcad: we did about 2 steps in debugging and then it goot too complicated for remote debugging |
| 14:59.35 | poolio | dtidrow: I think I might buy that, I need an external. Is that recommended or are you just going off price? |
| 14:59.38 | poolio | brlcad: alright, I'llget on that |
| 15:00.08 | brlcad | poolio: I think it's just the price |
| 15:00.15 | brlcad | 200 for a TB is pretty sweet |
| 15:09.45 | dtidrow | yeah, that was just the lowest I've seen a 500GB external at |
| 15:10.01 | dtidrow | non-rebated price, that is |
| 15:10.32 | dtidrow | seen a few that were $100 post-rebate, but the real price was around $125-$130 |
| 15:58.47 | *** part/#brlcad thing0 (n=ric@124-168-109-27.dyn.iinet.net.au) |
| 16:19.08 | poolio | brlcad: hrm, I'm having some issues understanding the internal representation of the union tree and such. I see that if the leaf is OP_SOLID, it stores region and soltab data. If I modify the soltab, and write out the new union tree, is the soltab for the shape that was modified (in the node of the union tree) going to modify the shape which that nodes represents? |
| 16:22.16 | poolio | Or would I have to retrieve the internal object, and modify the idb_ptr, and write out the internal object? |
| 16:28.42 | brlcad | I believe you have to do the latter |
| 16:30.34 | brlcad | not 100% positive, but my vague recollection is that you have to write out objects one at a time, and writing out the tree basically amounts to writing out a bunch of combinations (and leaving the leaves alone) .. could be mistaken. feel free to either provide a routine in librt that does this, or let me know if the routine that writes out the tree does it already :) |
| 16:46.52 | poolio | yeah it's the latter |
| 16:48.54 | poolio | brlcad: I don't think the solid and region data is written out |
| 17:07.21 | *** join/#brlcad iday (n=jlowens@bz.bzflag.bz) |
| 17:08.29 | iday | ls -al |
| 17:18.44 | *** join/#brlcad poolio (n=poolio@c-69-251-3-107.hsd1.md.comcast.net) |
| 17:20.40 | *** join/#brlcad MinuteElectron (i=cdcy1qlt@gateway/web/cgi-irc/irc.net/x-e7aca8bc90d1efb0) |
| 17:21.30 | MinuteElectron | brlcad: I only have 11 minutes before my session runs out, is there anything that needs doing that is urgent? |
| 17:30.25 | MinuteElectron | g2g my internet session is over |
| 17:38.56 | *** join/#brlcad Elperion (n=Bary@p54877F0D.dip.t-dialin.net) |
| 17:41.38 | *** join/#brlcad dtidrow (n=dtidrow@host131.objectsciences.com) |
| 18:00.37 | brlcad | ack |
| 18:00.49 | dtidrow | ack? |
| 18:00.50 | poolio | a bit late? |
| 18:00.53 | brlcad | yup |
| 18:01.03 | brlcad | needed him to enable my drupal account access |
| 18:02.02 | poolio | if you've got root access can't you just fudge with the files and get it yourself? |
| 18:02.19 | brlcad | of course |
| 18:02.29 | poolio | just more effort / not proper? |
| 18:02.53 | brlcad | not worth the effort/time, even if mildly trivial |
| 18:02.56 | brlcad | i can wait |
| 19:18.36 | Maloeran | From MinuteElectron, I'm curious to understand this concept of timed "internet sessions". I thought internet connectivity was eternal, as permanent as life itself. My believes are shaken |
| 19:20.06 | poolio | Ever been to an internet cafe? |
| 19:20.16 | poolio | :) |
| 19:27.56 | brlcad | Maloeran: maybe he runs his computer off of a UPS and is only able to charge it with a bicycle generator ;) |
| 19:29.47 | poolio | brlcad: hackaday? |
| 19:30.51 | poolio | brlcad: I've been tweaking the crossover/reporduction setup and it is still getting stuck on a sphere... |
| 19:32.41 | poolio | It's weird... like if I try to do any sort of scaling using the number of nodes in the tree it seems to always converge on a sphere |
| 19:33.07 | brlcad | sounds like a bug :) |
| 19:33.46 | poolio | dur :P |
| 19:34.40 | poolio | brlcad: I think the fitness value is being truncated somewhere, and all the fitness values are turning out the same, or something... I'm gonna keep digging, I had it working before I incorporated tree depth into the fitness equation |
| 19:35.10 | poolio | also, if I have the time I'd be curious to write some sort of plugin/routine for beset where you could specificy the fitness equation :) |
| 19:36.08 | brlcad | heh |
| 19:36.48 | brlcad | a gui would be more immediately useful than pluggable fitness equations so long as there are parameters for the pop size, mutation rates, crossover rates, etc |
| 19:36.59 | brlcad | but that would be kinda interesting, yeah :) |
| 19:37.27 | poolio | well, the issue is I need to fine tune the equation to make it work, like how much of a penalty for tree depth, how much |
| 19:37.30 | poolio | wait |
| 19:37.35 | poolio | I guess it's really just factoring in tree depth :P |
| 19:38.16 | poolio | It's also getting to the point where testing is a pain in the butt. Takes like a minute to run and a minute to generate the visualization |
| 19:38.34 | poolio | I run smaller tests, but I need to do moderately sized ones to really check stuff |
| 19:39.24 | brlcad | until you get two sphere's working, there's little point in working towards more ;) |
| 19:39.26 | poolio | and also, the GUI isn't useful if the backend is b0rked :) |
| 19:39.44 | poolio | brlcad: Well, the issue is I'm not sure whether to do mutation, I feel like crossover+reproduction should definitely work on the two spheres example |
| 19:39.46 | brlcad | or even matching arbitrary primitives (from a list) |
| 19:40.00 | brlcad | that would be my assertion as well |
| 19:40.17 | brlcad | I feel you should definitely be able to converge on two spheres |
| 19:40.22 | poolio | matching arbitrary primitives should already work, the issue is just spawning a population that is a good representative of the problem space |
| 19:41.17 | brlcad | should and will are very different ;) |
| 19:41.40 | poolio | :\ |
| 19:41.50 | poolio | hmm, slightly better results, let me upload |
| 19:44.36 | poolio | Hehe, mged does surprisingly well drawing 400 objects at once :) |
| 19:45.08 | brlcad | :) |
| 19:45.27 | brlcad | most real models have thousands of objects |
| 19:45.51 | poolio | brlcad: http://poolio.org/index.php?q=node/7 |
| 19:46.06 | brlcad | that's actually one of the things mged's relatively good at in comparison, it can open Pro/E models that Pro/E can't even open |
| 19:46.22 | poolio | yeah, but my machine is chugging on the 400 |
| 19:47.28 | brlcad | nice, that is much better |
| 19:48.08 | brlcad | it still got stuck but it actually seemed to converge roughly in the vicinity of the geometry fairly well |
| 19:49.31 | poolio | Yeah but I'd still expect better results from what I thought was such a trivial example |
| 19:50.46 | poolio | reducing the problem space gave a lot better results |
| 19:56.30 | poolio | brlcad: here: http://poolio.org/files/mon_1.jpg |
| 19:56.57 | poolio | I'm gonna grab a bite to eat while I run a larger test. |
| 20:06.32 | brlcad | there's still something really fish |
| 20:06.48 | brlcad | i mean it basically converged to a single best after just the fourth iteration |
| 20:07.48 | poolio | yes, which doesn't make much sense |
| 20:07.52 | poolio | it could have to do with mutation/reproduction rates |
| 20:07.57 | brlcad | either sample population is too small, or mutation rate is too low, or mutation and/or crossover isn't working would be my guess |
| 20:07.58 | poolio | well there is no mutation |
| 20:08.11 | brlcad | ah, no mutation yet |
| 20:08.15 | poolio | it's just that crossover isn't producing any better individuals |
| 20:08.23 | poolio | although...let me find this quote, one sec |
| 20:08.28 | brlcad | still, even with just crossover and random generation |
| 20:08.36 | brlcad | how are you currently doing crossover? |
| 20:09.16 | poolio | well there is no random generation |
| 20:09.21 | poolio | ok the current setup is thus: |
| 20:09.45 | poolio | a) spawn initial population -- currently done by creating 3 spheres at random positions in a certain limited domain with a random radius |
| 20:10.02 | poolio | and then |
| 20:10.04 | poolio | for each generation |
| 20:10.09 | poolio | <PROTECTED> |
| 20:10.16 | poolio | actually let me just write this up |
| 20:10.19 | poolio | it's a lot for IRC :P |
| 20:10.49 | brlcad | crossover really needs to be pretty complex enough to allow a configuration parameter defined such that the top N (# or %) proceed unmodified, the bottom M (# or %) are killed, and of the remaining middle perform your random crossover pairings |
| 20:11.50 | poolio | hmm |
| 20:11.56 | brlcad | for those killed, newly generated are spawned of course |
| 20:12.01 | poolio | I don't just use the top N |
| 20:12.21 | poolio | I'm using the tournament selection method, where the probability of selecting an individual correlates to its fitness |
| 20:12.29 | poolio | but theoretically the most fit individual could not be selected |
| 20:13.15 | brlcad | i'm saying that selection is what you use for the "middle", but that there needs to be some knob for unmodified progression and death as well |
| 20:13.46 | poolio | Should there really be though? |
| 20:13.58 | brlcad | anything that matches the input within a tolerance of 95%, for example, might be a desired configuration |
| 20:14.01 | poolio | From what I read it is good to keep the population diverse and include unfit individuals |
| 20:14.11 | brlcad | it is good to include unfit |
| 20:14.28 | brlcad | the upper in is just a knob (that can be zero, or weighted, etc) |
| 20:14.43 | poolio | So you're saying, include some top %, cut some bottom %, and perform the selection on the middle % |
| 20:14.44 | brlcad | generally, it's just one or two candidates, depending on the population size |
| 20:14.59 | poolio | and essentially remove the middle and bottom, replacing them with the new individuals created from the selection of the middle %? |
| 20:15.40 | poolio | So keep top N, remove bottom M, and do what I've been doing on the entire population for what's left? |
| 20:15.48 | brlcad | yes |
| 20:15.57 | brlcad | mind you, N and M are exceptionally small |
| 20:16.30 | poolio | Alright, but even with that I feel like I should be getting better results. I know that I should implement that, but I'd like to make sure it can converge first |
| 20:16.42 | brlcad | you can crossover with one retained to fill a killed spot, but the retained is still retained |
| 20:17.22 | brlcad | you should be able to converge even without that, but I think that will be eventually be necessary for more complex models |
| 20:17.23 | poolio | hmm, I'm not quite sure what you mean by that. |
| 20:17.33 | poolio | yeah I agree |
| 20:17.49 | brlcad | the bias injects new material into the population to work with and prevents a local minima from keeping you stuck indefinitely |
| 20:17.56 | poolio | when you say "but the retained is still retained" you're saying the top N you've selected are retained and kept? |
| 20:18.11 | brlcad | with simulated annealing, you can increase that M to something much larger if you do get stuck on a bad answer |
| 20:18.27 | poolio | alright |
| 20:18.30 | brlcad | yes, that's what I mean |
| 20:18.38 | poolio | and how does the bias inject new material? I thought it just included more of old? |
| 20:19.23 | poolio | hmm |
| 20:19.33 | poolio | My reproduction rate was quite high, that's probably part of it |
| 20:19.38 | brlcad | so you have AAA BBB CCC DDD .. AAA is kept, DDD is killed, AAA BBB CCC are potentially crossed |
| 20:20.17 | poolio | Oh alright, so include AAA in selection? |
| 20:20.22 | poolio | not just BBB CCC? |
| 20:20.23 | brlcad | and a new EEE can be injected to fill remaining slot |
| 20:20.32 | brlcad | that's a knob, you should allow it |
| 20:20.52 | brlcad | otherwise it's just dead material |
| 20:21.48 | poolio | k |
| 20:22.48 | brlcad | so you could end up with AAA AAB BBC EEE or AAA BBC CCB EEE or AAA ABB BBC EEE, etc |
| 20:23.13 | brlcad | or even AAA AAB BBC CCB |
| 20:23.24 | brlcad | depends on your selection rates |
| 20:23.29 | poolio | yeah |
| 20:24.18 | poolio | It still converges almost immediately with 90% crossover rate |
| 20:24.52 | brlcad | have it calculate and print out your average population fitness each iteration |
| 20:25.12 | brlcad | as well as the min/max |
| 20:25.17 | poolio | k |
| 20:27.38 | brlcad | since it very well could fine a "really good" initial guess on just the first iteration, yet continually improve the average fitness after a few hundred iterations to the point that it finds a new best |
| 20:30.04 | poolio | weird. average is pretty much constant, min fluctuates greatly, and max is constant |
| 21:27.18 | poolio | brlcad: argh. still not getting good results. I might just implement mutation and then try again. I don't see why it's converging so early... maybe I need to try a larger propulation, I mean the problem space is pretty big |
| 22:09.27 | poolio | brlcad: I'm off. This is really frustrating :\ |
| 22:09.41 | poolio | I don't have the patience to develop software... |
| 22:09.59 | CIA-29 | BRL-CAD: 03poolio * 10brlcad/src/gtools/beset/ (beset.c fitness.c population.c beset.h): more tweaks. two separated spheres still don't work... |
| 22:19.17 | brlcad | :) |
| 22:24.29 | brlcad | software development doesn't necessarily require patience, research generally does though |
| 22:30.59 | brlcad | your project is more the latter, and part why it's a harder problem. had you picked a path tracer, you'd probably be looking at pretty images by now ;-) |
| 22:32.46 | *** join/#brlcad IriX64 (n=IriX64@bas2-sudbury98-1096601105.dsl.bell.ca) |
| 22:34.09 | IriX64 | what does acromania do |
| 22:34.54 | IriX64 | i won't try it :) |
| 22:36.05 | IriX64 | brlcad is busy in libitcl3.2 so i thought id play while i wait on this update :) |
| 22:37.23 | IriX64 | sigh, cygwin is underappreciated you know |
| 22:41.41 | *** join/#brlcad b0ef (n=b0ef@062016141081.customer.alfanett.no) |
| 22:42.44 | IriX64 | http://rafb.net/p/4ft7tl62.html <--- hah should get a server op to test this :) |
| 22:59.56 | *** join/#brlcad b0ef (n=b0ef@062016141081.customer.alfanett.no) |
