 |
| wirthi [Free-DC] 2004-01-11 13:34:44 | Hi, is is one with low priority: could you scale the axis that displays "#gen"? I don't know how it works when using the sampleresults.dat (including quite high generations), but I'm using an isolated system and it's quite impossible to see the difference between gen. 0 and 10 on an axis of 0-1000. Perhaps the max-value of that axis should be the highest generation in the results.dat? Thanks, Wirthi |
| Stephen Brooks 2004-01-16 09:11:09 | That feature is now in the v4.33a that is now available on the main muon page. I will be away until the beginning of February on an accelerator-physics training course in the US... so I've left v4.33 up there too in case the new one doesn't work. HB Pencils, also sold as "Moron's Choice" Graphite Cigars. |
| wirthi [Free-DC] 2004-01-18 02:11:08 | Thanks, working great! I just wonder now: I have 1000+ results im my file, best one at ~1,5 (all computed by myself). The highest generation i've reached is 3 though. Shouldn't it be higher? I mean, it rather sounds like luck to me if you can reach that high with only 3 changes on the original (random) generation? Or have I misunderstood the way how this generation numer is computed? I had assumed it's 0 for random results and MA  gen(x),gen(y))+1 if results x and y are combined to a new result (higher generation of your parents, plus one)?Wirthi |
| [OCAU] badger 2004-01-18 14:42:31 | not quite, #gen shows the type of sim as explained by stephen here.quote: thus you will only get values from 0-3 www.BadgerMotorsport.tk Proudly sponsored by GRX-Computers |
| wirthi [Free-DC] 2004-01-20 06:26:21 | Thanks, that explains things. I had thought the number means the real "gen(eration)" of the result. Wirthi |
| Stephen Brooks 2004-01-24 16:05:01 | Ah, they have computers here in the US too. Thus I am able to post, but briefly. Err yes, "#gen" probably isn't the most lucid name for that parameter - I think I had in mind that it showed how the gen(ome) was gen(erated). I'm not sure how generation number would be useful, especially since some have two parents that might come from different generations themselves. I do keep track of the date submitted now, so overall I can get a time-series look at where the whole optimisation is going. HB Pencils, also sold as "Moron's Choice" Graphite Cigars. |
| [DPC]Stephan202 2004-01-25 05:03:18 | Assuming that it's very unlikely that two different results have the same checksum, I'm wondering if you could include the checksum one or two parent results if aplicable. Then on the server side you can, using the checksum as an identifier, track back the evolution of the highest results. That may give give you an interesting insight in how many generations were done and may even help to semi-random select, say, 25% of the results in the sampleNNN file. (I'm saying 25% because fully random adding some results is good too.) Just a brainstorm  --- Dutch Power Cow. MOOH! |
| Stephen Brooks 2004-01-25 09:12:39 | That's not at all a bad idea, because it would also allow things that are impossible under the current architecture, such as noticing that mutating genome X to X+delta produced a big improvement, so trying X+2delta as well. If I'm going to do this properly (and more genome-information will come soon anyway, such as one or two the parameters of the #gen type used) I'll want at least a 64-bit checksum. Ideally, it should act as a checksum and unique ID as well (so there should be perhaps 256 valid checksums per result and the program chooses one of these to avoid clashes). Keeping the ID unique on a project-wide scale would be more difficult - when I receive the results I'd have to do clash-avoidance on the checksums and then... nuts... I'd have to update all the linkage between results too. But it is possible, and would be best to go in when I re-do the database software I'm using to manage results. HB Pencils, also sold as "Moron's Choice" Graphite Cigars. |
