Sounds very good. I know that I use the "~U" command too so that it doens't count the U turn as part of the length when searching. I am very strong when it comes to parsing data, writting parsers, writting scripts that will turn the ACube output directly into a webpage layout, stuff like that. So you guys don't have to worry about filtering through data besides making them all triggerific!
We need someone to write up a bunch of txt files with all the input strings. Perhaps even separated into q,h,s metrics. But organized in a really nice way. It looks like it's something that I could run next weekend. Just a lucky coincidence I'm doing a bit of computer lab admin this weeka and setting up 20 brand new workstations (multi-processor) that should help out big time. I've been running ACube for over 6 years now, so I know how it's done. -Doug Li --- In [email protected], "cmhardw" <[EMAIL PROTECTED]> wrote: > > Hey Doug, > > Wow that would be awesome! I can start coming up with some search > strings that I always use. > > Also, I think we should come up with a set procedure for the searching > so that every case gets the same amount of search time. > > Here is what I think should be done based on my experience with the T > and U cases, but I'm of course open to suggestions. > > First search for quartern turn optimized algs and print out all of them. > > The startup string for ACube is then > java -cp ACube3.jar ACube qa > > Then search for all algs (this includes ones in RULM, RUF, etc.. since > it prints every alg, or at least most of them, more on that later). > > Then since we have to accomodate all styles we should do the same > thing in also HTM and STM. > > So the other two search strings would be > java -cp ACube3.jar ACube a (for HTM, since ACube defaults to HTM) and > java -cp ACube3.jar ACube sa > > Now, everyone gets a copy of the QTM optimized list, and then the STM > users also take the STM list and the HTM users take the HTM list too. > > When searching for an alg try to find the best ones on the QTM list > that are also on either the HTM or STM list. This gives you an idea > of what a fast alg in either HTM or STM is like. Then compare you QTM > and HTM dual optimized alg to other algs on the HTM list and see if > one is better. > > That is how I found all my ZBLL algs. The QTM list is an amazingly > powerful filter for algs, and I always use it in conjunction with the > HTM list (STM users would do well to also use it for their STM algs I > believe). > > So the most important is that we have a search string with each of these > java -cp ACube3.jar ACube a > java -cp ACube3.jar ACube qa > java -cp ACube3.jar ACube sa > > Also, the program is more likely to find suboptimal length cases if > you search within your preferred faces. > > Suboptimal length algs tend to be the faster ones for me (not always > of course). > > So you would again search in QTM for algs in the RULM group say, and > also in the HTM group. > > It is a tedious process, but the algs you get out of it the best > quality I've been able to find. > > So this would mean that we may need to do a lot of searches on each case. > > For example take a new H case. > > Now search that case in QTM with > java -cp ACube3.jar ACube qa > > after that search is over, run another one still within QTM for every > preferred move group. RUF, RULM, etc.. > > Now restart ACube in HTM and STM and do the same, do an all search, > and also search for our preferred face groups. > > This may be very repetitive, and not the most efficient way. I am not > a computer programmer, so those with computer experience please help > to optimize this process! > > Basically, this is the procedure I used to find my best algs for ZBLL. > > I think the most important is that any search must have a QTM > counterpart to compare to the HTM and STM search to dual optimize each > alg for HTM and QTM or also STM and QTM. > > Also, it is very important that we also search specifically for moves > in our preferred move groups, since Acube doesn't print out every > single alg it finds, but only 95-99% of them. Also this maximizes > your chances of finding the suboptimal length algs that are super fast > (suney type algs are a good example, ACube optimal searches weed them > out almost 100% of the time, since they are almost never optimal > length) I could only ever find suney type algs with searches in RUL > moves specifically. > > Again these are just my thoughts, you guys have more computer > experience than me by far! Let's come up with a rigid procedure for > generation raw algs! This will be a very important substep to moving on. > > Chris > > --- In [email protected], "Doug Lee" <[EMAIL PROTECTED]> wrote: > > > > First I'd like to say that this is an excellent time to get this > > going. Winter break is coming up and I believe Chris will be out of > > school very soon. > > > > I would like to help with maintaining web content since that is > > something I'm good at. > > > > Also, we don't need a group C. I can generate faster than anyone > > here probably, since I work in a computer lab (and have two 3Ghz > > computers in front of me). Just give me a txt with all the input > > sequences and I bet I can get like 300 done a day. > > (Remember to use the ~U and the mask code for say RULM.) > > This should be done by group A. > > > > We need much more group D people, heck everyone should be a group D > > person. > > > > > > -Doug > ------------------------ Yahoo! Groups Sponsor --------------------~--> Get fast access to your favorite Yahoo! Groups. Make Yahoo! your home page http://us.click.yahoo.com/dpRU5A/wUILAA/yQLSAA/MXMplB/TM --------------------------------------------------------------------~-> Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/zbmethod/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
