 |
| Slartibartfast 2003-10-07 03:17:45 | I was thinking of the following: Have a small util running in the systray monitoring your Muon1 installation's files every 'x' minutes. Results.txt > 10kb -> stop the client and spawn manualsend.exe Then check if there's any results in results.dat that are better than the ones in best100.txt, copy that to results.dat and append those results, and start the client again. Poll http://stephenbrooks.org/muon1/best100.txt every 3 hours for a new version and download if newer to work with the best results so far. That and your usual graphed overviews of results. Would this be anything people might want to employ? [This message was edited by Stephen Brooks on 2003-Oct-08 at 11:50.] |
| [DPC]Stephan202 2003-10-07 08:00:35 | Sounds good, but remember that this will really narrow down the area in which we search. Most evolutionary paths will not be walked. That could mean that the best configuration is never found. --- Dutch Power Cow. MOOH! |
| Slartibartfast 2003-10-07 09:21:22 | poin taken, most paths would indeed not be tried out. from observation however I noted that my own two highest scores (2 and 3 in the best 100), have a really similar configuration. the #1 has a tantalumrodz of +1 and tantalumrodr about 109% of mine. looking at the top #10 configurations, all are very close in both their yields as well as those two values. this likely either means that this vicinity is where the best scores are found and that's why this file is offered to optimize searches, or it means that so far most scores have been found in that neighbourhood but as you suggest possibly yields of 10+ will be found elsewhere. I don't want to discard the validity of your point, but logically if in the end using the best100 file would harm the results it wouldn't be available for download? maybe mr. brooks wants to offer his opinion on the matter. |
| [DPC]Stephan202 2003-10-07 11:46:29 | You got a point there. It is something I thought about myself before, but I choose not to make a point about it. In the past (previous client versions) the bestNNN.txt file was released much later in the project and only updated every now and then. (That is why I created http://stephan202.qik.nl at the time - warning: don't use it for this version). To be honest: I think it would be better if Stephen did not publish the best100.txt at this time. I'm no expert though... --- Dutch Power Cow. MOOH! |
| Stephen Brooks 2003-10-07 11:59:39 | In relation to the "10KB" thing, I designed it to automatically send every 100KB so the servers didn't get too swamped with small files - thinking 100KB was a bit more sensible (sends every day or two). The best100 on this optimisation was an experiment on my part. My general instinct about it had told me on previous runs that it should only be published occasionally, but obviously that means the project computers hardly have a channel of communication between them. This time I thought I'd try to see how well it went if everyone was working right on the head of the comet-shaped blob of high designs being checked. Basically we'd be working on variations around one point, but we'd try a lot of them, a bit like a single very very fast computer running a unified results.dat. But now I realise that it's not _quite_ as good as that. Muon1 with a full database will select from it in a balanced way, sometimes taking results from quite far down the pile in order to bring variety to the calculation. This suggests that the way to improve my current best100 system is to make it not the best100, but rather something like ranks 1,2,3...9,10,20,30...90,100,200,300... etc., spreading out through the distribution, but including the very best. This time around I may have already messed it up because a lot of people have submitted reruns of results on the leading edge, so actually most of the database is now concentrated in that area. But I could think about doing it a way other than by rank, for instance selecting results by muon percentage. It doesn't make any sense: that's why they call it "virtual" |
| Slartibartfast 2003-10-07 13:54:03 | wouldn't a while of running the 'bestmuons100.txt' (to call it that) on most clients reintroduce that variety that's missing now? I don't mind starting again, it's about the science in any case. Yet if rerunning with a varied selection from the previous results, and those are used as seeds for future runs it would right itself again automatically. At least depending on how the client selects from the results.dat, random, interpolate or what have you. |
| [DPC]Stephan202 2003-10-07 14:07:28 | That's true. I think it may get right if most people stopped downloading the best100.txt file. I only downloaded it once and I think I won't download it again any time soon. --- Dutch Power Cow. MOOH! |
| Slartibartfast 2003-10-07 15:07:52 | curious though... isn't the current best100.txt the best 100 muon percentages already? as the solenoids upto 15cm stats list is sorted on muon percentages, and it does have the same top 10 (accounting for some people not showing there twice, although they do in best100.txt). it's certainly limiting the families selected from, but the results do keep improving from what I can see. I'm currently running a quarantined job again on one machine, 9.18xxx first run, 9.20xxx 2nd run, on the third run now. Even so I still get jobs bombing out, below 0.01 even at times, as a result of the client sometimes taking a random job? Assuming the same thing is happening on other people's machines then increasing the amount of time between the new results made available from 3 hours to 12 hours, or even 24 hours, wouldn't there be enough jobs with randomized seeds about to keep it all balanced? |
| [DPC]Stephan202 2003-10-07 22:53:27 | I don't think so, because most (if not all) random configurations have a very low yield. And it seems configurations with higher yields are much more likely to be used by the client (at least, it would seem to make sense if Stephen programmed it that way). Thus I believe the random configurations add little value to the project at this stage. They seem to be useful only in the beginning (yields < 1%). Am I right about this, Stephen? --- Dutch Power Cow. MOOH! |
| Stephen Brooks 2003-10-08 02:13:50 | Yes, that's basically right. Random results are one of four techniques it uses for choosing new designs. Two of the others involve taking two high designs and interpolating between them somehow, which will be useless right now given the results are so close together it might even try interpolating between a design and something that's nearly identical! The final technique, however, is random mutation, and that only takes one result and changes a certain number of the parameters by a certain amount. That will still work in our regime, so what muon1 will currently be doing is trying results in the viscinity of the current focal point - that point will gradually move "uphill" due to mutations that take it in the right direction. It doesn't make any sense: that's why they call it "virtual" |
| Stephen Brooks 2003-10-08 03:51:51 | Have a look here (also available as a RAR file). That will now be updated every 3 hours too and gives a nicer cross-section through the stats scores. I'll link that up to the main site, and probably take down the best100 this evening. It doesn't make any sense: that's why they call it "virtual" [edit] For those of you that like big files, there's also a sample500 RAR file (text version). Note that due to the lack of results in the gap between the manually seeded ones and the 'natural' ones, this file's score distribution has some jumps in it. [This message was edited by Stephen Brooks on 2003-Oct-08 at 12:07.] |
| Slartibartfast 2003-10-08 04:16:25 | I'm starting on a run from the sample500.txt right now, I'll post results every few hours. |
| ZeonX[OCAU] 2003-10-08 04:38:37 | Nice setup you got going there. I havn't used the best results file and i'm trying to just get results the normal way. Any results help the project i suppose. And i'm running 4.13 atm anyway... hahaha. |
| Slartibartfast 2003-10-08 05:41:52 | I'm thinking of switching over one of the machines to 4.13 to help out with that report, probably the 1.6Ghz notebook. |
| Slartibartfast 2003-10-08 08:08:49 | alright, notebook is plugging away at v4.13 now, but as the results written are in a much shorter form it'll take a while before it reaches enough of a size to upload  this machine has employed the best500.txt file for the last few jobs now and it's given the following results so far: sfinall=998;sfinalf=999; 9.077565 (353.2 Mpts) [v4.32b] {9F9F9C4A} sfinall=863;sfinalf=240; 0.114444 (26.0 Mpts) [v4.32b] {A1F73790} sfinall=998;sfinalf=998;#runs=5; 9.182218 (1668.6 Mpts) [v4.32b] {A2D824F4} note that even though a score of 9.20 something was present in the file it was quarantined, as the initial run produced an output of 9.21xxxx (queue.dat), this then got normalized over the other 4 runs to this score. all in all it looks to be too soon to comment on this approach improving the spread of results, as I've had this kind of output from the continual update of results.dat with the best100.txt file. it'll take a while before these results are uploaded as most jobs are still ones of 300+ Mpts, and hence take a while to get a decent sized results file. I'll probably post another bit of output tomorrow. Is there any way we can tag the output seeded from this new file so the results can be verified to improve at all? |
| Pollock[Romulus2] 2003-10-08 20:56:25 | Two different breeds in the twaeking process here. The original tweak started at 1.40 and it spawned a seperate breed at 6.60, now working on one of them. Currently at 8.50 with a lot of room for improvement. It is obviously different from the current toplist and should be ready to go in a day or two. Then I can start on the other breed. That one is on hold at 6.60 and should grow rapidly. Lots of room for improvement there. |
