Cultural center \'De Brakke Grond\' has been transformed from a quiet gallery into a bustling hub of all things Drupal for the Amsterdam Drupal Conference. Over 50 developers and users have already attended, and new faces continue to appear every morning. If you are nearby, please drop by!
Hot topic of discussion has definitely been the new forms API, which opens up a bunch of new avenues for modules and themes. End-user usability is another important point that many people are interested in.
Yesterday in particular had several interesting sessions about the Drupal community itself, and how we can keep up with its exponential growth. These were complemented by the Drupal Birds of Feather session at Euro OSCON down the road where we met many new Drupal users.
In fact, it seems there are so many ideas floating around here, that the catchphrase this week has become: \'We should have an API for that...\'
For more info, check the following resources:
Today marks my one year anniversary as a registered member on drupal.org. To mark such an august occasion :0) I’m here to debut my new blog, David (in words).
Now for some history. A couple of years ago after watching a movie, I surfed around the web to find out more about the movie and the actors. One of the sites I came to was powered by Postnuke. I liked what I saw and decided that I’d use Postnuke on my own site. As such, my first CMS powered website was up. Now, Postnuke worked for me… mostly. I had some struggles with things (like modules) but I really liked the design. At that time, I did look at other CMSs, including Drupal.
',1129872372),(207,1,'Drupal 4.6.4 / 4.5.6 released','http://drupal.org/drupal-4.6.4','','Drupal 4.6.4 is available for download. Drupal 4.6.4 is a maintenance release that fixes problems reported using the bug tracking system, as well as 3 security vulnerabilities (two \"less critical\", one \"not critical\") that affect all previous versions of Drupal. Since the vulnerabilities are also present in the Drupal 4.5 series, Drupal 4.5.6 is released as well.
Upgrading your existing Drupal sites is strongly recommended.
There are no new features in these installments. For more information about the Drupal 4.6.x release series, please consult the Drupal 4.6.0 release announcement.
',1133387100),(209,1,'Looking for Drupal@GNOME supporters','http://drupal.org/node/40000','','GUADEC, the GNOME desktop users and developers international conference, is moving to a Drupal based website. We want to invite GNOME friends fluent with Drupal in the development of the site in order to make a better use of this web platform. Not only to help organising a great GUADEC 2006, also to contribute to the debate about the gnome.org website evolution.
Some of us think that Drupal could be useful to the GNOME project in many aspects. Showing examples and prototypes helps a lot when discussing with colleagues not familiar with this great tool. If you want to help selling Drupal to the GNOME community, the GUADEC test site and the gnome-web-list are good starting points.
',1133773767),(222,1,'My Drupal book has arrived!','http://drupal.org/node/42201','','Today I received a very nice package in the mail; my Drupal book is finally available!
![\"Robert](\"http://drupal.org/files/holding_drupal_book.medium.jpg\")
![\"\"](\"http://www.assoc-amazon.com/e/ir?t=d-20&l=ur2&o=1\")
Soon after the conference, Dries was approached by Matt Wade, an editor at Apress, about writing 1/3 of a book about building online communities. The other 2/3 would discuss phpBB and WordPress, two other immensely popular projects that address different niches. As Dries was too busy with his studies to write a book, he introduced me to Matt.
The result was a project that lasted until October; writing the first book about Drupal. I knew that I would need lots of support, and therefore asked James Walker to be the technical editor. This turned out to be a very good move, as James is a \"Drupal Rockstar\" who always knows the smallest technical details, and has worked with many many clients and other people to know which parts of Drupal are hard to grasp, and where the hidden sticking points are. He helped me decide how to present the many concepts and capabilities that are not always intuitive.
It is that time of the year again! After predictions for 2004 and 2005, we continue this tradition about what Drupal will do in 2006.
Looking back to the predictions for 2005, it seems that some predictions were far from right, if serious at all. Some posters, however, turned out to be true fortune tellers...
',1135172967),(223,1,'Druplicon on the cover of PHP | Architect','http://drupal.org/node/42243','','![](\"files/php-architect-cover.jpg\")
PHPArchitect is a printed magazine devoted to spreading information about PHP and related projects like MySQL, PHPMyAdmin and... Drupal! Look at the cover of the current issue and you will see 70% of the frontpage is taken by our beloved Druplicon.
Organizations, these days, are demanding content management applications, from company homepages to large, community websites. Author Titus Barik shows you how you can let Drupal help you build these sites quickly and efficiently by building on a common, modular framework.
On this page, Druplicon is introduced to the public as:
',1135411672),(229,1,'Uwe Hermann\'s Drupal article in PHP Solutions is out','http://drupal.org/node/43279','','If you\'ve already seen the cover (and if not, take a look!), you may be wondering what that raindrop-type-character is all about. It\'s called the \"Druplicon,\" and it\'s the mascot and logo for a PHP content management system that is gaining more and more momentum: Drupal. Titus Barik takes you through the basics of how to use Drupal to create a real website, in short order, and without rewriting that same form-processing code.
Uwe Hermann has written a comprehensive article in the current issue of PHP Solutions, German edition Ausgabe 1 2006 (13). Uwe walks his readers through installing Drupal, and considers topics like multisite setups from the very beginning. He pays careful attention to describing how one would create a portal site (music portal in his article), where the site would be accessed using different subdomains, such as rock.example.com, blues.example.com and classical.example.com. This includes using database prefixing, and Uwe provides assistance on using the database prefixing scripts which ship with Drupal.
',1136371046),(230,1,'Sign up for sessions, DrupalCon Vancouver','http://drupal.org/node/43527','','Please help us better coordinate the DrupalCon portion of the conference by signing up for sessions! Read on for more details...
The afternoon portions of the conference will CMS-specific, and we\'ve got quite a few drupal-specific session topics for you to choose from! I\'d like to encourage you to take just a few minutes and indicate which sessions you\'ll likely attend by visiting our signup site, http://scratch.blkmtn.org , logging in w/ YOUR_DRUPAL.ORG_USERNAME@drupal.org and your drupal.org password (you can also create a new account on that site if you prefer, but logging in via distributed authentication will let you right in), browsing the available sessions, and signing up for those which you will likely attend.
Signing up is easy: Just below the description of a session, you\'ll see a small form--enter your email address and any comments/suggestions you have for the session moderator, and click \'Sign up\'. That\'s it!
Here\'s a few important things to remember about the process:
',1136512174),(231,1,'San Francisco Drupal User Group a success','http://drupal.org/node/43665','','The Drupal meetup last night was a huge success. At least 36 people attended at the new CivicSpace Labs/GoodStorm offices on the San Francisco Bay. Many people showed up looking to meet someone who actually knew what Drupal was. Others just wanted to let out their pent up Drupalness.
',1136590939),(232,1,'OSCMS/DrupalCon Vancouver T-Shirts On Sale now!','http://drupal.org/node/43687','','We\'re doing things a bit different this time around. Goodstorm will be printing the t-shirts, and you\'ll order and pay through them. If you want your shirt to be waiting for you in Vancouver, you must order no later than February 1st. Afterwards, Goodstorm will still be able to sell shirts a la carte, and ship them anywhere in the US--if you\'d like a shirt shipped directly to you, then order after February 1st... :)
',1136608388),(235,1,'Handbook update -reorganization progress','http://drupal.org/node/44233','','As announced in the documentation team mail list, I\'ve been re-organizing the handbook. A lot of work has gone into this since I started last week and I have come to the conclusion that we have a lot of content. Hopefully some of it is easier to find. I thought I\'d mention that this is still an ongoing work in progress and probably will be for the rest of this month.
',1136971575),(191,1,'Drupal.org survey','http://drupal.org/node/33460','','I\'d like to invite you to participate in the Drupal.org survey. The objective of this survey is to get feedback on the Drupal.org website, and to prioritize the work we should put into improving Drupal.org. The survey will run for about one week, and the results of the survey will be published in 2-3 weeks. Preliminary results will be presented at the Drupal conference in Amsterdam. Thanks for your support.
',1128784441),(236,1,'DrupalCon Vancouver, last call for signups, and a new site!','http://drupal.org/node/44527','','Attention all DrupalCon Vancouver attendees and session moderators: we have a shiny new site!
Sessions are listed under \'Full Session List\' in the top navigation bar.
',1137118478),(233,1,'Drupal 4.7.0 beta 3 available','http://drupal.org/drupal-4.7.0-beta3','','Starting the new year off with a bang, the Drupal development team is pleased to announce that the third Drupal 4.7.0 beta release is available for immediate download at http://drupal.org/files/projects/drupal-4.7.0-beta3.tar.gz! This beta release marks an important step towards the final Drupal 4.7.0 release and significant progress from our previous beta release: we\'ve fixed over 100 bugs since the last beta release and more than 150 bugs since the first beta release. Here is the changelog. However, there are more bugs to be found, reported, and fixed before Drupal 4.7.0 can be released. The good news is that you can help!
',1136835602),(226,1,'Last call for Vancouver DrupalCon sessions!','http://drupal.org/node/43221','','Folks, I\'ll be sending out information for people to begin signing up for the Drupal-specific sessions at the OSCMS, Vancouver Conference soon--January 5th to be exact. For more information on existing sessions, and for contact information to suggest a new session, please visit the conference page. If you would like to add a session, please submit both the session topic and a short description of the session, preferrably no later than January 6th. It would be tremendously helpful to find a session moderator as well... :)
',1136329942),(227,1,'Drupal meet-up January 5th 3-6PM, San Francisco','http://drupal.org/node/43232','','There is a Drupal Meet-up at the new CivicSpace Labs offices in San Francisco this Thursday. The meeting is being convened to support communication amongst developers and the small businesses being built on the Drupal platform. We are open to your ideas about what to cover. Please contribute thoughts to the agenda.
',1136332432),(239,1,'Bay area bugfix meetup Tuesday, Jan. 24th','http://drupal.org/node/45057','','We will meet at Ritual Roasters in San Francisco from 1 to 6pm to tackle the issue queue. Stop by for a few hours to review, test, and create patches. Working in the same space will allow us to collaborate on issues. A good overview of how to help is at the Jan. 19 bugfix post.
',1137464321),(192,1,'Drupal is heading for Amsterdam','http://drupal.org/node/34109','','On Tuesday the DrupalCON will start in Amsterdam, the Netherlands. More than 50 Drupal coders, administrators and enthusiasts from Chile to China and from South Africa to Estonia gather together, truly showing off the global strength of the Drupal community. We will share our thoughts, present new ideas and implement them in code during these three days.
Not only will we share our thoughts within our own community, we will also be communicating with other open source projects. The following well-known people are scheduled to speak during our conference:
We hope to learn from them and each other and that this will be reflected in our data model and code. We will post more updates during the conference itself on drupal.org. It looks like we are heading for a very exciting time in Amsterdam!
',1129314518),(193,1,'Drupal administration user experience survey','http://drupal.org/node/34297','','Hello, in order to support user experience improvements which will be made during the upcoming Drupal 4.7 code freeze we have conducted over a dozen user experience interviews. The results of those interviews have lead to a web survey which will allow us to prioritize the Drupal Administration issues.
Here is the survey: http://surveymonkey.com/s.asp?u=631841425065
We will be collecting results for a month. The results will be presented to the Drupal community leadership, lead by Dries, and a team of prominent user experience professionals who will help us to prioritize administration improvements in Drupal 4.7. We will then work with the development teams to focus our efforts. The last survey we did lead to over 200 responses and significant improvements in Drupal documentation.
Cheers,
Kieran
Check out my DrupalCon AMS 2005 Opening video (18MB MPEG4 file) over on Now Public. My thanks again to Bèr, Bert, and Dries for organizing it and for the Drupalers who participated! I love events like these!
This is a video of closeups of people who were at this Drupal conference but I didn\'t label the people so unless you were there, or know how some of the people look in real life, it may not be worth the download. But killer groove called \"Spy beats\" from Drupaler Colin Brumelle and his band, Greenroom.
',1133420519),(199,1,'Promoting Drupal security','http://drupal.org/node/36526','','As many of you might remember, we setup a security announcement newsletter, a history of all security advisories, and an RSS feed with the most recent security advisories. We strongly advised Drupal administrators to sign up for the list. With the recent drupal.org survey we asked people if they are subscribed to either the Drupal newsletter or the Drupal security announcements, and if so, how. Turns out that a fair amount of survey participants were not subscribed to either mailing list (see graph, read more). Additional research showed that the security announcements page is not very popular in terms of page views and that, to date, only 850 people subscribed to the security announcements by e-mail ...
',1131267785),(201,1,'What database do you use with Drupal?','http://drupal.org/node/37268','','Drupal 4.5.7 and Drupal 4.6.5 are available for download. These are not security releases but regular maintenance releases that fix problems reported using the bug tracking system. There are no new features in these installments.
For more information about the Drupal 4.6.x release series, please consult the Drupal 4.6.0 release announcement, the Drupal 4.6.1 release announcement, the Drupal 4.6.2 release announcement, the Drupal 4.6.3 release announcement, and the Drupal 4.6.4 release announcement. For more information about the Drupal 4.6.5 release, click \"read more\".
Following Drupal\'s involvement in the Google Summer of Code program, Robert Douglass was interviewed by Liz Gannes of Red Herring magazine. The issue has just hit the news stands, and the article, \"Google U\", is a full page from the 48 page publication. In the section Winning Hearts, where Google\'s motivation for spending $2 million on open source is pondered, Drupal get\'s it\'s shining moment:
And that kind of money is a significant infusion for open source. It means an emerging project like Drupal, a content management platform run by Belgian students that mentored 10(sic) Summer of Code participants, can get the equivalent of “hiring a highly qualified developer for an entire year to work for us,” says Robert Douglass, an American developer in Germany who spearheaded Drupal’s involvement. “Fifty-thousand dollars earmarked for Drupal development—that’s really astounding.”
You can read the full article at RedHerring.com.
Thanks again to Robert (see his post) and the whole team of mentors (and students!) that were involved with th
',1132180937),(202,1,'The Progressive runs Drupal','http://drupal.org/node/37359','','I used to subscribe to The Progressive and now I\'m glad to see that they put my subscription dollars to good use and bought themselves the best CMS on the market; Drupal. Perhaps someone at The Progressive might want to share your story about how you chose Drupal and what it is like running a major news site with it?
Update Nov. 13: The Progressive is a well established voice in the fight for protecting free speech and the environment in the United States. They serve their readership with articles and interviews that tend to be intellectual and free-thinking with a bent towards activism.
',1131825295),(196,1,'CSC-SY.net Migrated to Drupal','http://drupal.org/node/34926','','CSC-SY.net has been recently migrated from PHP-Nuke to Drupal, the migration process involved moving stories, forum topics, polls, posts and comments, private messages, and user accounts, we also had to port the theme we were using with PHP-Nuke to PHPTemplate, localize Drupal into Arabic, and finally configure Drupal to provide PHP-Nuke\'s features (and much more), details of the reasons behind the migration, and of the process itself follow.
',1130022751),(205,1,'Performancing.com, a new professional blog about blogging, runs Drupal and has reviewed Drupal','http://drupal.org/node/37977','','Performancing.com is a group of blogging professionals who write about how to blog. They use Drupal. They also compared 10 blogging platforms for the purpose of blogging and Drupal comes out well (#2). Their site is interesting especially because of how well they are building a community almost overnight. By advertising on sites like BoingBoing.net and Technorati.com, they are generating tons of traffic, and lots of people are signing up and leaving comments to their quite interesting and plentiful posts. Worth checking out for many reasons.
',1132238468),(206,1,'The \"What database do you use with Drupal?\" poll summary','http://drupal.org/node/38486','','Hello, I\'m Piotr Krukowiecki, aka Cvbge, your new (for almost three months) PostgreSQL maintainer. As some people have noticed, there was a poll running on drupal.org last week. This text summarises feedback gathered in the poll\'s comments, lists problems with PostgreSQL support in Drupal, and shows my plans on how to improve it. It also includes a help request (last item, but probably most important!)
',1132651329),(219,1,'GoodStorm: a major ecommerce site for non-profits built on Drupal','http://drupal.org/node/41504','','Big news folks- CivicSpace Labs has just helped a major new eCommerce company launch this week using on CivicSpace/Drupal, at http://www.GoodStorm.com. We think this is going to be one of the highest traffic CivicSpace sites ever launched, and it\'s already yielding a lot of new useful Drupal code(organic group stores, e-commerce products, sub-products, apparel, paypal pro, e-civicrm).
GoodStorm is explicitly aimed at helping non-profit organization earn income to support their work through merchandising-- which is to say that it provides production, online sales, and fulfillment of printed branded apparel as an online service. We think that where CivicSpace helps to provide online tools to organizations, GoodStorm will help the organizations help themselves to become financially sustainable.
',1134833223),(198,1,'Drupal article in Swedish computer magazine','http://drupal.org/node/35785','','The November issue of the Swedish computer magazine \"Datormagazin\" has a 5 page article on Drupal, entitled: \"CMS in all its beauty\" (Swedish: \"CMS i all sin skönhet\"). The translated introduction reads: \"To edit a website can be super-tedious work, but also absolutely wonderful. Much depends on what tools one has available. With Drupal, which is a Content Management System, it all gets much simpler.\"
',1130713295),(214,1,'Pack your skis, we\'re going to Vancouver','http://drupal.org/node/40480','','All Drupal developers should plan to make their way to the west coast of Canada for the event to kick off your year: the Open Source CMS Summit and DrupalCon. As the event page says, this will be a developer-centric event focused on collaborating together on future directions and everyone\'s favourite topic -- APIs!
There will likely be some time for relaxing as well, with skiing being excellent that time of year on Vancouver\'s coastal mountains or even up at Whistler, for some of the best mountains in the world.
Chad Phillips and Angie Byron are the two main Drupal organizers, with Boris Mann and Roland Tanglao doing the Vancouver local organizing and helping with the summit as a whole. Please join the Drupal conference mailing list and/or check out the wiki to add your own ideas to make this a great gathering of Drupalites. Oh, and of course, flip the switch in your user profile to get listed on the attendees page.
',1134116039),(213,1,'[RFC] GameAPI: Embedding RPGs into Drupal','http://drupal.org/node/40354','','I am pregnant (woohoo!). In six short months, I will be disappearing from active duty in the Drupal community for a good long time. I\'d like to discuss a desire I\'ve had for years and years, only reworked for our beloved codebase. In short: an HTML based browser role playing game, though ultimately an API.
',1134020961),(210,1,'Drupal, The Onion and Google','http://drupal.org/node/40245','','Due to just some plain sillyness, I did a search for \"THE\" using Google. Why anyone would search for something like that is quite beyond me, but I try to maintain my sanity with this excuse: I wanted to search for a word in the English language that is guaranteed to get a lot of hits - got 9.5 billion hits for the word.
However, whether or not Kobus is sane is not the reason for this post. Go ahead, do the search yourself. My results indicated that The Onion was on the top of the list for a Google search for the word \"THE\". Some others indicated that they saw The Onion as the third result, which is still impressive. A search just before I started to write this page indicated again that The Onion was first in the list for me (see screenshot in attachment).
Big deal, but, did you notice how the listing for The Onion is even higher up than The White House and higher than The Economist?
Get to the point, you say? Okay. The Onion uses Drupal. Whether this indicates Drupal\'s search engine friendliness or their hard work, or a combination of the two, I don\'t know, but simply knowing that such a popular site is using Drupal is quite heart warming!
',1133939954),(212,1,'Bughunt competition','http://drupal.org/node/40383','','With the release of 4.7.0 beta1, I will be co-sponsoring a bug hunt competition to be concluded with the release of 4.7.0. The prize will be a combination of 150USD from the Google Summer of Code and an additonal 200USD donated by me.
I will count the opened, non-duplicate issues marked as \"CVS\" or \"4.7...\" in the Drupal project issue\'s tracker between now and 4.7.0 are released. First place will be 200USD, second will be 100USD, and third will be 50USD. In reality, anyone using Drupal will be the winner as the more bugs found and fixed before 4.7.0 means a stronger build for every user.
',1134051974),(216,1,'Daddy knows best: Tim Berners-Lee uses Drupal','http://drupal.org/node/41322','','We owe a lot to Tim Berners-Lee, whether you know him or not. In short, he is the father of the World Wide Web and the creator of the very first web site. Recently, as part of MIT\'s Decentralized Information Group\'s web site, he published his first blog entry with honest-to-goodness \"blogging tools\", explaining that:
... I have had the luxury of having a web site which I have write access, and I\'ve used tools like Amaya and Nvu which allow direct editing of web pages. With these, I haven\'t felt the urge to blog with blogging tools. ... That said, it is nice to have a machine [do] the administrative work ... and it is nice to edit in a mode in which you can to limited damage to the site. So I am going to try this blog thing using blog tools.
It should bring us all great pleasure to know that Tim\'s first experience with \"blogging tools\" is our own Drupal.
',1134684295),(224,1,'GUADEC logo and Drupal theme contest','http://drupal.org/node/42939','','GUADEC is the main event of the GNOME community, celebrated once a year. We have recently adopted Drupal as the platform of the GUADEC\'s website (http://beta.guadec.org) and we have decided to launch a contest to choose a GUADEC logo and Drupal theme: Artists Wanted.
The works need to be submitted before 31/jan/06 and the winner gets 2 GUADEC vip passes, 2 return tickets to Vilanova (Catalonia, Spain) and one week accommodation for both participants. The event is the last week of June and Vilanova is in the Mediterranean coast, 45km south of Barcelona. We are studying the possibility to use Drupal for gnome.org too, so your theme could end up being adopted/adapted in the main site as well.
We hope this contest will humbly contribute to the increase and diversity of Drupal themes available. All the works are submitted publicly and the winner is decided by a jury in which the community is also represented (more).
',1136126938),(218,1,'Drupal 4.7.0 beta 2 available','http://drupal.org/drupal-4.7.0-beta2','','Drupal 4.7.0 beta 2 is now available for download at http://drupal.org/files/projects/drupal-4.7.0-beta2.tar.gz. This is the second beta release of the forthcoming Drupal 4.7.0 release.
Over 50 bugs have been fixed since beta 1, but we know there are still more to find, report, and fix. Being a community, this is a community effort and we need as much of the community as we can get to come forward and help us out so that we can get this system to a stable 4.7.0 release. Read on for more information about how you can help.
',1134740066),(237,1,'Happy birthday Drupal','http://drupal.org/happy-fifth-birthday','','Today, five years ago, Drupal 1.0.0 was released! The following snippet is taken directly from the original announcement:
Today, drop.org announces the release of drupal 1.00 after an extensive period of testing. Drupal is a full-featured content management/discussion engine using Apache/PHP/MySQL and suitable to setup a news-driven community or portal site similar to kuro5hin.org and slashdot.org. Current features include discussion forums, web-based administration, theme support, an open submission queue, content management, a modularized design, PHP sessions, user management with access control and username/profanity/hostname filters, error logging, a public diary module, an affiliate site module, backend/headline generation (RSS/RDF) and much more.
To celebrate this event:
![\"Happy](\"http://drupal.org/files/happy-birthday.jpg\")
Three weeks ago, I launched a Drupal.org survey, the objective of which was to get feedback on the Drupal.org website and to prioritize the work we should put into improving it. The results of this survey are below.
',1130744589),(200,1,'Sprint testing Drupal 4.6.3 against PHP 5.0.5 and up','http://drupal.org/node/37161','','So, I spoke with Dries about this and he said go ahead.
There are some reported issues with 4.6.3 and php5 (and misc other stuff). Let\'s see if we can get some folks to look at the issues for 4.6.3 and any that have patches for them, test (only test 4.6.3 not HEAD) and review. Pay paticular attention when you comment.
Dries said if we can get some good reviews on pending patches he is willing to release a Drupal 4.6.4 soon. If we can get this down early enough this weekend (Saturday night), maybe we can get this done before his business trip.
I have more news about a 4.7 release candidate timeline, but will post seperately. In the meantime, lets see if we can get some quality reviews on pending patches (or some more patches to review as well)
',1131659841),(211,1,'Drupal 4.7.0 beta 1 available','http://drupal.org/drupal-4.7.0-beta','','We are pleased to announce that the first Drupal 4.7 beta release is available. It is available for immediate download at http://drupal.org/files/projects/drupal-4.7.0-beta1.tar.gz.
This beta release marks an important step towards the final Drupal 4.7.0 release, which hopefully will be released in 4-6 weeks. Drupal 4.7.0 will be our most exciting release to date, with some cool new features and many under the hood improvements. Some enhancements include; free tagging, contact form functionality, easier menu management, a better default theme engine (PHPTemplate), improved search functionality, theme-specific block regions, improved PostgreSQL support, themeable forms, a better upgrade script, better revisions handling and much more.
At the same time Drupal 4.7.0 will be a tad smaller (better code re-use, the queue module and comment moderation moved to the contributions repository) and a tad faster. Finally, to liven up your various Web 2.0 dreams, we sprinkled the code with AJAX in an attempt to simplify some administrative tasks. (Yes, it should degrade gracefully.)
',1134050303),(217,1,'Bug fix party - this Saturday, December 17 2005','http://drupal.org/node/41320','','On Saturday, December 17 at 18:00GMT (noon eastern time US, 7pm central european time), I will be welcoming the whole Drupal community to a Bug Fixing party. Even if you can\'t attend at that time, you can still help out. See below.
We are determined to make 4.7 our most powerful, and least buggy release to date. Almost everyone can contribute in one way or another. Our party is coordinated via Internet Relay Chat (IRC). Meet fellow Drupalites in the room entitled #drupal-bugfix on the server chat.freenode.net. If you are unfamilar with IRC, you will need to download an IRC client application to your PC.
',1134685555),(234,1,'Bugfix party on Wednesday January 18, 2006','http://drupal.org/node/44182','','On Wednesday, January 18, 2006 18:00GMT (noon eastern time US, 9am US West Coast Time, 7pm central european time), the Drupal community is invited to a Bug Fixing party. Even if you can\'t attend at that time, you can still help out. Click \'read more\' for details.
',1136937164),(240,1,'Drupal.org outages today (Jan 20, 2006)','http://drupal.org/node/45657','','I wanted to bring people up-to-date on events that happened last night regarding drupal.org. I am paraphrasing most of this from an email our lead systems engineer here at the OSL sent me (he and his folks are working on).
First thing is first, there was no loss of data during this outage. The Drupal infrastructure is backed up on a nightly basis.
',1137810376),(238,1,'Lullabot Drupal Podcast No. 1','http://drupal.org/node/44950','','The first of our weekly Drupal podcasts is now online. This episode is an intro to Lullabot and what we do along with a cursory overview on the current state of Drupal.
Future podcasts will include:
- Intro to Drupal
- Intro to drupal.org
- Developing for Drupal
- Designing for Drupal
- \"Important\" Drupal modules
as well as Drupal news, reviews, interviews, and opinions.
For those of you not subscribed to the development mail list and are curious, (why are you not subscribed if you are interested?) the conditions for Dries rolling a release candidate are now announced below.
The short answer is, it depends on how many bug fixes are submitted and how many people help review them. Possibly as early as next week if the level of critical bugs continues to go down as they are fixed and a base level of stability is met.
',1132181335),(220,1,'My CMS Can Kick Your CMS\'s Ass','http://drupal.org/node/41938','','So this past September I was at a conference called Web of Change up in beautiful British Columbia. Shockingly, there were almost as many women at this event as men, and one of the great geek girls I met was the coordinator, Sarah Pullman.
Since this year\'s conference she\'s been hanging out with the Vancouver Drupal geeks and determined to learn to use the platform (and other web tools) to help social change organizations and other people doing good for the world get their message out. She\'s just started her first couple of sites on the Bryght platform...
Of course I had to hook her up with a t-shirt, so she could spread the Drupal love across the land.
',1135149016),(225,1,'Dries is drinking own champagne','http://drupal.org/node/43031','','After half a decade of being the lead of the best code any Content Management Framework has, Dries\' personal site has been Drupalised at last. Dries published his first post (titled \"first-post\") just in 2005 (Sat, 2005-12-31), so Steven can buy some Duvel for Dries while you can add his feed to your aggregator/RSS reader.
\"Proost\" Steven and Dries!
',1136205075),(228,1,'\"Done\" is a four letter word','http://drupal.org/node/43305','','An often raised question on drupal.org is, \"when will release x.y be done?\". And most often the first answer received will be \"It is done when it is done.\" Or it is just as likely the answer will be phrased in a somewhat less friendly manner: \"When is the last time you patched a bug or tested a patch?\". While one of these is a question, both qualify as good answers to the question \"when willl it be done?\". This is because software development in the Open Source differs in some important points to traditional software development. In this posting you can read what the difference is and how you can make, be, that difference.
',1136384461); /*!40000 ALTER TABLE `aggregator_item` ENABLE KEYS */; UNLOCK TABLES; -- -- Table structure for table `authmap` -- DROP TABLE IF EXISTS authmap; CREATE TABLE authmap ( aid int(10) unsigned NOT NULL auto_increment, uid int(10) NOT NULL default '0', authname varchar(128) NOT NULL default '', module varchar(128) NOT NULL default '', PRIMARY KEY (aid), UNIQUE KEY authname (authname) ) TYPE=MyISAM; /*!40000 ALTER TABLE `authmap` DISABLE KEYS */; -- -- Dumping data for table `authmap` -- LOCK TABLES authmap WRITE; INSERT INTO authmap VALUES (1,17,'pdboddy@drupal.org','drupal'); /*!40000 ALTER TABLE `authmap` ENABLE KEYS */; UNLOCK TABLES; -- -- Table structure for table `blocks` -- DROP TABLE IF EXISTS blocks; CREATE TABLE blocks ( module varchar(64) NOT NULL default '', delta varchar(32) NOT NULL default '0', status tinyint(2) NOT NULL default '0', weight tinyint(1) NOT NULL default '0', region tinyint(1) NOT NULL default '0', path varchar(255) NOT NULL default '', custom tinyint(2) NOT NULL default '0', throttle tinyint(1) NOT NULL default '0' ) TYPE=MyISAM; /*!40000 ALTER TABLE `blocks` DISABLE KEYS */; -- -- Dumping data for table `blocks` -- LOCK TABLES blocks WRITE; INSERT INTO blocks VALUES ('aggregator','feed:1',1,5,1,'',0,0),('archive','0',1,0,1,'',1,0),('block','4',1,0,0,'',0,0),('block','2',1,0,0,'',1,0),('block','3',1,0,0,'',0,0),('block','1',1,0,1,'',1,0),('blog','0',1,0,0,'',0,0),('forum','0',1,0,0,'',0,0); /*!40000 ALTER TABLE `blocks` ENABLE KEYS */; UNLOCK TABLES; -- -- Table structure for table `book` -- DROP TABLE IF EXISTS book; CREATE TABLE book ( nid int(10) unsigned NOT NULL default '0', parent int(10) NOT NULL default '0', weight tinyint(3) NOT NULL default '0', format tinyint(2) default '0', log longtext, PRIMARY KEY (nid), KEY parent (parent) ) TYPE=MyISAM; /*!40000 ALTER TABLE `book` DISABLE KEYS */; -- -- Dumping data for table `book` -- LOCK TABLES book WRITE; /*!40000 ALTER TABLE `book` ENABLE KEYS */; UNLOCK TABLES; -- -- Table structure for table `boxes` -- DROP TABLE IF EXISTS boxes; CREATE TABLE boxes ( bid tinyint(4) NOT NULL auto_increment, title varchar(64) NOT NULL default '', body longtext, info varchar(128) NOT NULL default '', type tinyint(2) NOT NULL default '0', PRIMARY KEY (bid), UNIQUE KEY info (info), UNIQUE KEY subject (title) ) TYPE=MyISAM; /*!40000 ALTER TABLE `boxes` DISABLE KEYS */; -- -- Dumping data for table `boxes` -- LOCK TABLES boxes WRITE; INSERT INTO boxes VALUES (1,'God\'s Algorithm Calculations','![](\"files/pics/lemniscate.png\")
','God\'s Algorithm Calculations',0),(2,'FTP Archives','![](\"files/archive.png\")
![](\"files/qmark.png\")
','Frequently Asked Questions',0);
/*!40000 ALTER TABLE `boxes` ENABLE KEYS */;
UNLOCK TABLES;
--
-- Table structure for table `bundle`
--
DROP TABLE IF EXISTS bundle;
CREATE TABLE bundle (
bid int(10) NOT NULL auto_increment,
title varchar(255) NOT NULL default '',
attributes varchar(255) NOT NULL default '',
PRIMARY KEY (bid),
UNIQUE KEY title (title)
) TYPE=MyISAM;
/*!40000 ALTER TABLE `bundle` DISABLE KEYS */;
--
-- Dumping data for table `bundle`
--
LOCK TABLES bundle WRITE;
/*!40000 ALTER TABLE `bundle` ENABLE KEYS */;
UNLOCK TABLES;
--
-- Table structure for table `cache`
--
DROP TABLE IF EXISTS cache;
CREATE TABLE cache (
cid varchar(255) NOT NULL default '',
data longtext,
expire int(11) NOT NULL default '0',
created int(11) NOT NULL default '0',
headers text,
PRIMARY KEY (cid)
) TYPE=MyISAM;
/*!40000 ALTER TABLE `cache` DISABLE KEYS */;
--
-- Dumping data for table `cache`
--
LOCK TABLES cache WRITE;
INSERT INTO cache VALUES ('variables','a:35:{s:12:\"update_start\";b:0;s:13:\"theme_default\";s:9:\"xtemplate\";s:9:\"site_name\";s:24:\"Domain of the Cube Forum\";s:9:\"site_mail\";s:29:\"cubeman@cubezzz.homelinux.org\";s:11:\"site_footer\";s:0:\"\";s:9:\"anonymous\";s:9:\"Anonymous\";s:14:\"site_frontpage\";s:4:\"node\";s:8:\"site_404\";s:0:\"\";s:9:\"clean_url\";s:1:\"0\";s:5:\"cache\";s:1:\"0\";s:19:\"file_directory_path\";s:5:\"files\";s:19:\"file_directory_temp\";s:4:\"/tmp\";s:14:\"file_downloads\";s:1:\"1\";s:17:\"date_format_short\";s:11:\"m/d/Y - H:i\";s:18:\"date_format_medium\";s:14:\"D, m/d/Y - H:i\";s:16:\"date_format_long\";s:15:\"l, F j, Y - H:i\";s:14:\"xtemplate_logo\";s:58:\"![\"Logo\"](\"themes/xtemplate/default/logo.gif\"){kind=logo}
\";s:23:\"xtemplate_primary_links\";s:45:\"Back to Main\";s:25:\"xtemplate_secondary_links\";s:0:\"\";s:21:\"date_default_timezone\";s:6:\"-18000\";s:17:\"xtemplate_mission\";s:42:\"Discussions on the mathematics of the cube\";s:20:\"xtemplate_search_box\";s:1:\"1\";s:21:\"xtemplate_avatar_node\";s:1:\"0\";s:24:\"xtemplate_avatar_comment\";s:1:\"0\";s:24:\"xtemplate_avatar_default\";s:0:\"\";s:20:\"chameleon_stylesheet\";s:37:\"themes/chameleon/marvin/chameleon.css\";s:16:\"drupal_cron_last\";i:1131588061;s:17:\"comment_cron_last\";i:1131595261;s:14:\"node_cron_last\";i:1131595261;s:13:\"drupal_server\";s:32:\"http://www.drupal.org/xmlrpc.php\";s:16:\"drupal_directory\";s:1:\"1\";s:11:\"site_slogan\";s:19:\"Cube lovers returns\";s:12:\"site_mission\";s:79:\"To promote mathematical discussions about the Rubik\'s Cube and related puzzles.\";s:14:\"ping_cron_last\";i:1131595261;s:18:\"xtemplate_template\";s:7:\"default\";}',0,1131602094,''),('archive:calendar:28-1-2009','\n\n| « January 2009 | ||||||
| Su | Mo | Tu | We | Th | Fr | Sa |
| \n | 1 | \n 2 | \n 3 | \n |||
4 | \n 5 | \n 6 | \n 7 | \n 8 | \n 9 | \n 10 | \n
11 | \n 12 | \n 13 | \n 14 | \n15 | \n 16 | \n 17 | \n
18 | \n 19 | \n 20 | \n21 | \n 22 | \n 23 | \n24 | \n
| 25 | \n26 | \n 27 | \n 28 | \n29 | \n 30 | \n 31 | \n
| « December 2008 » | ||||||
| Su | Mo | Tu | We | Th | Fr | Sa |
| \n | 1 | \n 2 | \n 3 | \n 4 | \n 5 | \n 6 | \n
7 | \n 8 | \n 9 | \n 10 | \n 11 | \n 12 | \n 13 | \n
14 | \n 15 | \n 16 | \n 17 | \n 18 | \n 19 | \n 20 | \n
21 | \n 22 | \n 23 | \n 24 | \n 25 | \n 26 | \n 27 | \n
28 | \n 29 | \n 30 | \n 31 | \n \n |
\r\nIn your example, this means that the order of the element U\'FD divides the order of the generated group <U,F,D>. This takes care of the factor 90.\r\n
\r\nYour conjecture claims that the length of the sequence (in the example it is 3, the length of U\'FD) further divides this quotient (also called the index).\r\n
\r\nThe fact that the only sequences you allow are those with all different faces ensures that this potential divisor is <=6. It is not surprising that this is an actual divisor because the group order will have an abundance of small prime factors.\r\n
\r\nLet\'s take any move sequence of length 5, involving 5 different faces. The group generated by the 5 faces will certainly have more than 5 corners and more than 5 edges that are permuted. The group order therefore has two factors 5. The element itself might have an order that is divisible by 5 if it permutes some of the pieces around in a 5-cycle. It cannot have an order divisible by 5^2=25, because there are no 25-cycles possible. Therefore your conjecture will certainly be true with regards to the prime 5.\r\n
\r\nThe order of the group will have lots of factors 2 and 3, because of the orientations of the pieces. Your conjecture will therefore certainly hold for lengths 2,3,4 and 6 as well. For example a length 3 sequence will involve at least 7 corners, so the group has a factor 3^6 from the orientations alone. To get an element with an order high enough to be a counterexample, it would have to involve a 3^5-cycle at least.\r\n
\r\nI think this pretty much proves it.\r\n\r\n
\r\nJaap\'s Puzzle Page:\r\nhttp://www.geocities.com/jaapsch/puzzles/','134.146.0.12',1110461511,0,0,'1/','a:1:{i:0;i:0;}'),(29,28,20,1,'More than a conjecture, but less than a theorem','I tend to agree, but I\'m going to try to work out all the cases. I don\'t think it\'s a huge number.\r\n\r\nHere\'s another problem but this time I\'m not going to make any conjectures. \r\n\r\nCan we reach all the positions of the cube if we only use processes formed by an additive list? In other words: Can all elements of the cube exist as elements of an additive list?\r\n\r\n\r\n','127.0.0.1',1110722318,0,0,'1.1/','a:1:{i:0;i:0;}'),(30,29,20,4,'No','No, that is not possible, and can be shown by a straightforward counting argument.\r\n
\r\nLet m1 .. mn be the moves of an additive list, and let P=m1 m2 ... mn be the whole move sequence that is repeated.\r\n
\r\nThe elements on that list are then:
\r\n{m1, m1 m2, ..., P, P m1, P m1 m2, ..., P^2, P^2 m1, .... }\r\n
\r\nIf I remember correctly, the maximal order of any element of the cube group is 1260. An additive list therefore contains at most 1260*n < 10^4 elements.\r\n
\r\nHow many additive lists are there?
\r\nThere are less than 18^6 of six moves, less than 18^5 of 5 moves, and so on. There are certainly less than 10^8 all together.\r\n
\r\nTherefore all additive lists together contain less than 10^12 positions, much less than the whole cube group.\r\n\r\n
\r\nJaap\'s Puzzle Page:\r\nhttp://www.geocities.com/jaapsch/puzzles/','134.146.0.12',1110881448,0,0,'1.1.1/','a:1:{i:0;i:0;}'),(31,0,21,4,'coset spaces','Jerry,\r\n\r\nYou are correct that H is usually not normal in these cases, and that G/H is therefore not a group but merely a coset space. In fact, the four stages of Thistlethwaite\'s algorithm are also coset spaces and not actually groups.\r\n\r\nIn some way you probably know all the stuff I\'m going to write below, but I hope it helps you clarify your ideas a little.\r\n\r\nSuppose H is the subgroup of G consisting of movements of those 6 corners only, leaving the rest fixed. Let g be any element of G, i.e. any permutation of the cube.\r\n\r\nIf we apply g to the Start position, we get some mixed position (which I\'ll also denote by g).\r\nIf we first apply some h in H to the start position (which mixes only the 6 corners) and only then do g, we get a similar position (denoted by hg). This differs from position g only in those 6 corner pieces, where ever they happen to actually be on the cube.\r\n\r\nI am writing multiplication on the right here, so hg means apply h first and then g.\r\n\r\nAnyway, we want to treat hg for any h in H the same as g itself. In other words, the coset Hg contains all the permutations that, when applied to Start, are considered the same as g.\r\n\r\nSolving the puzzle in this context means applying moves to g until we get a position that is solved apart from those 6 corners.\r\n\r\nSo:\r\n\r\ng.m1.m2.m3.....mn = h for some h in H.\r\n\r\nor equivalently,\r\n\r\nHg.m1.m2.m3....mn = H\r\n\r\nYou thus start with Hg, multiply by m1 to get another coset H g1, multiply by m2 to get another coset H g2, and so on, until the coset you reach is H. This is the coset that contains the identity permutation.\r\n\r\nEven though H is not a normal group, you can still work with its cosets. Multiplying on the right (i.e. performing some moves) gives you a new coset.\r\n\r\n\r\nTo put this in a program, you want a way to encode a position g such that hg would give the same answer for any h in H. In the example you would encode only the two other corners, i.e. \r\n\r\nP = (location of corner 1)*7+(location of corner 2)\r\nO = (orientation of corner 1)*3+(orientation of corner 2)\r\nresult = P*9+O.\r\n\r\nThis way all the elements of the coset Hg get the same number. It is a mistake to try to encode the piece at each location - instead encode the location of each (distinct) piece as in this example.\r\n\r\nThe standard techniques still apply in this situation. The positions /orientations of the pieces are converted into one or more coordinates, so that every puzzle position is given by such a set of coordinates. You can then:\r\n\r\n- build transition tables (i.e. tables that give the new coordinate value resulting from applying any move to any previous coordinate value)\r\n- build pruning tables (tables giving the distance to start for all values of some subset of the coordinates).\r\n- build a God\'s Algorithm table (like a pruning table but giving the distance to start of all coordinate values, i.e. of all positions).\r\n\r\n\r\n> conjugates\r\n\r\nI don\'t know what you wish to do with conjugates, so I can\'t tell if you can still use them.\r\n\r\n> symmetry\r\n\r\nIf H has symmetry, then you can exploit it. I think you will never have the full symmetry of G, unless H is normal.\r\n\r\n> Sims tables\r\n\r\nSims tables normally encode which piece is at each location. What I did above is encoding the inverse, the location of each piece. The tail end of that encoding is the subgroup H which is simply chopped off.\r\n\r\n\r\n\r\nI have written a program in Java, where you can define a puzzle:\r\n- number of pieces of each type\r\n- the number of possible orientations of each\r\n- how many pieces are identical\r\n- the effect of moves\r\n- the starting position or positions\r\n- which pieces to cluster together into coordinates for the transition tables\r\n- which sets of clusters/coordinates to build pruning tables for\r\n\r\nand then you can define a position and it will attempt to solve it with a pruned iterative deepening search. It does not exploit puzzle symmetry in any way (though clusters can share transition tables if they have the same number of pieces of the same type). It has been useful to me for my website, allowing me to find short move sequences for specific cases, and for calculating God\'s Algorithm in small puzzles. Unfortunately it tends to get bogged down for larger puzzles. As it doesn\'t exploit symmetry, it needs more pruning tables, and so they can\'t be as large.\r\n\r\nJaap\'s Puzzle Page:\r\nhttp://www.geocities.com/jaapsch/puzzles/','134.146.0.12',1114498084,0,0,'1/','a:1:{i:0;i:0;}'),(32,25,14,13,'small world...','.\r\nThanks to everyone who wrote back about this question.\r\n\r\nFunny how small the world is; the paper many of you refer to as Shamir\'s method was written by a bunch of people whose main interest is Cryptography, the science of secret communication. This is indeed my field of research, including quantum cryptography and quantum teleportation (http://www.cs.mcgill.ca/~crepeau/index_en.html).\r\n\r\nFor the record the authors of the paper are Fiat, Moses, Shamir, Shimshoni and Tardos. It is the tradition in our field to list authors in alphabetical order, regardless of each other\'s contribution. A proper way to refer to their work is to use the accronym \"FMSST89\".\r\n\r\nOn may 22, 1987 Adi Shamir gave a lecture at MIT on early work towards FMSST89. I was a grad student at MIT at the time but unfortunately I was away on that day and missed his lecture...\r\n\r\nOf course Shamir is the most famous of these people (because of the RSA cryptosystem) but all five of them deserve our recongnition. Funny that \"RSA\" is indeed a very rare exception to the alphabetical order rule. I assume they knew the tremendous significance of their invention and decided to be listed according to contributions instead of alphabetically.\r\n\r\nTo summarize what I found in your answers and in e-mail discussions with some of you:\r\n 1) Tom Rikicki developped a C program that optimally solves Rubik\'s cube configurations (http://tomas.rokicki.com/rubsolv164.c) and requires 700Mb to run.\r\n 2) Herbert Kociemba developped \"cube explorer\" a windows-only program that also computes optimal solutions.\r\n\r\nBeing a Mac OS person, I didn\'t manage to try \"cube explorer\" yet. I am hoping to compile Rikicki\'s C program on my Mac but have not found the time to do that yet (I need to find a gcc compiler). I am not sure what method neither of these programs use exactly. Please correct me if I have missed anybody else\'s software...\r\n\r\nCheers, Claude\r\n','132.206.51.85',1115590011,0,0,'2.1.1/','a:1:{i:0;i:0;}'),(33,32,14,2,'Other programs','There are also\r\n\r\n(3) Herbert Kociemba\'s old program Cube Optimizer, available as C++ source code (easily compiled). Not as fast as the optimal solvers in the current Cube Explorer, but very useful for working in batch mode. \r\n\r\n(4) Mike Reid\'s program. C source only, but uses symmetry reductions and can do QTM or HTM. Needs a little fiddling around to get it to compile with non-GNU compilers. See\r\nhttp://www.math.ucf.edu/~reid/Rubik/optimal_solver.html\r\n\r\nEither program will run with about 90Mb RAM.','130.88.128.98',1115732503,0,0,'2.1.1.1/','a:1:{i:0;i:0;}'),(34,0,22,29,'Letter L pattern on all the six faces','About 20 minutes ago I hit upon a posting in news:sci.math by Herbert Kociemba (June 15th 2005 22:19) on antisymmetric Cube positions. So I am an absolute beginner in this forum.\r\n\r\nThe subject awakened memories from bygone times! In the 1980s I spent many hours with the Cube. I bought two copies; on one of them I studied what special positions arise when one systematically turns opposite faces thru a quarter-turn, both of them in the same screw sense with respect to the centre. \r\nAt a certain time I obtained a letter L (5 squares) in four of the faces and a mirrored letter L in the remaining two. Unfortunately I did not record the exact sequence of turns. I darenot restore the start position, afraid to lose this elegant six Ls position.\r\n\r\nIs this subject of sequences of special turns an existing specialism?\r\n\r\n\r\nI was much pleased to find that Rubik\'s Cube is after 25 years still alive and kicking.\r\n\r\n','82.92.86.208',1118873212,0,0,'1/','a:1:{i:0;i:0;}'),(35,34,22,4,'First of all, congrats to Mik','First of all, congrats to Mike and Herbert for the excellent work.\r\n\r\nJoher,\r\nYes, a lot of research has already been done on such special sequences. In particular, what you describe are anti-slice moves, and the group of positions you can get with just those moves (the anti-slice group) is well known.\r\n\r\nIf you take a look at my web site (link below), you will find a Java applet that allows you to restrict yourself to just those moves, as well as a built-in solver for it. Similarly, the group of positions reached with only half turns (the square group) is also represented there.\r\n\r\nCubie applet:\r\nhttp://www.geocities.com/jaapsch/puzzles/cubie.htm\r\n\r\nI would also recommend that you try to find a copy of David Singmaster\'s Notes on the Magic Cube, which sets out much of the groundwork of the theory of the cube, including a calculation of how many positions there are in the anti-slice group, or the square group.\r\n\r\nSingmaster\'s Cubic Circular magazine came out after his Notes, and can be found on my site.\r\n\r\nJaap\'s Puzzle Page:\r\nhttp://www.geocities.com/jaapsch/puzzles/','134.146.0.12',1118923493,0,0,'1.1/','a:1:{i:0;i:0;}'),(36,35,22,23,'I also would like to congratu','I also would like to congratulate Mike and Herbert for their excellent work.\r\n\r\nThe possibility of using inverses to reduce the size of the \"real\" cube space by approximately another factor of 2 was mentioned in Cube-Lovers. But nobody ever posted the detailed calcululations to Cube-Lovers. This certainly seems like the first time anybody has performed the calculations.\r\n\r\nAlso, the possibility of implementing this reduction in the size of the search space in a search program was mentioned in Cube Lovers. But to the best of my knowledge, nobody has ever implemented such a reduction. I am working on a new set of programs as we speak that will include this feature, but I am a long way from having the new programs in production. I\'m curious if Herbert has implemented this feature in any of his programs, or is planning to.\r\n\r\nFinally, some time after Dan Hoey posted his Polya-Burnside results to Cube-Lovers, Martin Schoenert performed the same calculations with about two lines of GAP code. Well, there were some GAP libraries behind the scenes that defined the Rubik\'s Cube group and also that defined the group of symmetries for the Cube. So those group definitions did not count against the \"two lines of code\". What I always meant to do and never did was to chase down what GAP was doing behind the scenes to implement its \"two lines of code\". It might have been doing something similar to Dan\'s Polya-Burnside calculations, or it may have been doing something entirely different. I don\'t know.\r\n\r\nSee\r\n http://www.math.rwth-aachen.de/~Martin.Schoenert/Cube-Lovers/Martin_Schoenert__Re__The_real_size_of_cube_space.html \r\n\r\nfor Martin\'s GAP calculation of the \"real\" size of cube space.\r\n\r\nJerry Bryan\r\n','68.47.230.99',1120694991,0,0,'1.1.1/','a:1:{i:0;i:0;}'),(37,36,22,2,'Reduction of search space?','> The possibility of using inverses to reduce the size of the \r\n> \"real\" cube space by approximately another factor of 2 was\r\n> mentioned in Cube-Lovers.\r\n\r\nInteresting -- I hadn\'t noticed this. The calculation seemed a natural thing to do after we\'d completed a scheme for classifying Cube positions by their \"magnetic symmetry\". (In Cube Explorer, Herbert has provided a tool to search for positions in a specified magnetic symmetry class).\r\n\r\n> Also, the possibility of implementing this reduction in the size \r\n> of the search space in a search program was mentioned in Cube\r\n> Lovers. \r\n\r\nI hadn\'t noticed this either. Do you remember when it was discussed?\r\n\r\nMike','130.88.128.98',1120756199,0,0,'1.1.1.1/','a:1:{i:0;i:0;}'),(38,37,22,23,'After diligent searching, I c','After diligent searching, I can\'t find a mention of a further reduction by a factor of two in the Cube Lovers archives. Either my searching has not been diligent enough, or (more likely) there was private E-mail about the subject that did not make it to Cube-Lovers. So my apologies.\r\n\r\nI will use the old Cube-Lovers convention that the group of 48 symmetries of the cube is called M. The normal way that symmetry can be used in a search of a large cube space space is simply to calculate for each position x the set of M-conjugates x^M, and to define a representative for each set of M-conjugates as \r\n\r\n y=Rep(x)=min(x^M)\r\n\r\n(x^M means {x\'mx | m in M} )\r\n\r\nThen, it is only the representatives that are stored and manipulated. The representatives are not very well behaved (they are not amenable to being stored in a Sims table, for instance), so managing and indexing large numbers of them is non-trivial. That is, there is some extra cost associated with gaining the approximately 48 times reduction in the search space.\r\n\r\nTo gain the additional 2 times reduction in the search space in a computer program, representatives have to be defined as\r\n\r\n y=Rep(x)=min(x^M union z^M) where z=x\'\r\n\r\nWhen searching cube space, given a representative y it is necessary to calculate all its neighbors -- those positions one move away. With representives in a search space reduced by 48 times, the neighbors of y are of the form Rep(yk), where k is a member of the set of allowable moves. With representatives in a search space reduced by 96 times, the neighbors of y are all the positions of the form Rep(yk) plus the all positions of the form Rep(y\'k), where k is defined as before. As an alternative, you could calculate all positions of the form Rep(yk) plus all the positions of the form Rep(ky).\r\n\r\nJerry\r\n','68.47.230.99',1120884528,0,0,'1.1.1.1.1/','a:1:{i:0;i:0;}'),(39,0,23,4,'Hi Jerry,\r\n\r\nCan you give an','Hi Jerry,\r\n\r\nCan you give an estimate on how long it took? Were you able to reuse a database from your previous attempts, or did you have to regenerate all of it from scratch?\r\n\r\nJaap\'s Puzzle Page:\r\nhttp://www.geocities.com/jaapsch/puzzles/','80.61.167.110',1120920173,0,0,'1/','a:1:{i:0;i:0;}'),(40,39,23,23,'It took about four months, ru','It took about four months, running around the clock.\r\n\r\nThe data had to be regenerated from scratch. There is no database, exactly. Rather, the positions are produced in lexicographic order. By producing the positions in lexicographic order, they don\'t really have to be stored and hence there is no database. The positions are produced in lexicographic order in order to detect and eliminate duplicate positions (those positions that may be produced by more than one sequence of quarter turns).\r\n\r\nWhat did have to be stored were all positions (or really, representatives of all positions, unique up to symmetry) of length 7q or less (7 quarter turns or less). By storing positions of length up to 7q, the program could calculate all positions out to 14q in the same amount of memory. However, calculating out to 14q would have taken about ten times longer, say about forty months. I decided to work on a developing a faster program rather than letting the existing one run that long.\r\n\r\nWhat actually happens is that all positions of length 7q are multiplied by all positions of length 1q, 2q, 3q, 4q, 5q, and 6q and the products are produced in lexicographic order. When duplicate positions are encountered, only one is kept and the shortest possible one is kept. For example, if |x|=7q and |y|=6q, then |xy| might only be 11q rather than 13q. Foe that matter, |xy| might be only 1q.\r\n\r\nFor that reason, all shorter products have to be recalculated on each run, even if they have been calculated before. On the other hand, the calculation of positions of length 13q took about 90% of the processing time and the calculations of shorter positions took only about 10% of the processing time. The same would be true if I told the program to calculate positions of length 14q. It would still be the case that only about 10% of the processing time would be spent recalculating the shorter positions that were 13q or less.\r\n\r\nJerry Bryan\r\n','68.47.230.99',1120939345,0,0,'1.1/','a:1:{i:0;i:0;}'),(41,0,23,23,'Sorry the table looks so stra','Sorry the table looks so strange. It looked fine when I posted it. The processing of HTML seems to have squeezed out all the blanks but one between columns, so the columns don\'t line up right.\r\n\r\nIf you do a View Source from your browser, the table looks pretty much ok, except that you do see some HTML tags that have been added by the software managing this forum. If I could figure out how to post html in my message (say a pre tag or a table tag), I could make it look right without having to do a View Source.\r\n\r\nJerry\r\n','68.47.230.99',1120939632,0,0,'2/','a:1:{i:0;i:0;}'),(42,0,23,23,'Table Lines up Correctly','I added a pre tag to the data and hoped that it might be left alone by the software managing this forum. Apparently it works. See below.\r\n\r\n
\r\n\r\nDistance\r\n from Patterns Positions\r\n Start\r\n\r\n 0 1 1\r\n 1 1 12\r\n 2 5 114\r\n 3 25 1068\r\n 4 219 10011\r\n 5 1978 93840\r\n 6 18395 878880\r\n 7 171529 8221632\r\n 8 1601725 76843595\r\n 9 14956266 717789576\r\n 10 139629194 6701836858\r\n 11 1303138445 62549615248\r\n 12 12157779067 583570100997\r\n 13 113382522382 5442351625028\r\n\r\n\r\nJerry\r\n','68.47.230.99',1120940623,0,0,'3/','a:1:{i:0;i:0;}'),(43,40,23,1,'Technical details','I would be interested to know the specifications of the machine which did the search (cpu type, speed, memory size etc), and if there was auxiliary storage used.
\r\n[ ^(1,9,35)(3,27,33)(6,43)(8,25,19)(11,30)(14,46,40)(16,22,41)(17,24), ^(3,27)(6,43,17,30,11,24)(8,25)(9,\r\n 35)(14,40)(22,41), ^(1,3,8,6)(9,33,25,17)(11,35,27,19), ^(1,17,41,40)(6,22,46,35)(9,11,16,14),\r\n ^(6,25,43,16)(8,30,41,11)(17,19,24,22) ]\r\n\r\n
In my previous post (3x3x3 cube ignoring edge locations), I neglected to mention how I defined edge orientation.
\r\nMy definition of edge orientation is based upon this list: (UF,UB,DF,DB,LU,LD,RU,RD,FL,FR,BL,BR).
\r\nThe letter pairs indicate the various positions of the edge cubes in terms of the two faces of the cube the edge position is part of. The first letter of each pair is considered the \"marked\" face or reference face. For example, the \"U\" face is considered the reference face of the UF edge position. (Likewise the edge cubie with the \"U\" and \"F\" colors has the \"U\"-colored face as its reference face.) If the reference face for an edge position is aligned with the reference face of the cubie located in that position, then the cubie is considered aligned. Else it is considered flipped.
\r\nThis convention for defining edge orientations allows all 48 cube symmetries to be applied without knowledge about which edge cubie is in what location. Applying a particular symmetry either preserves all the edge orientation reference faces, or flips all of them. So in either case, the edge orientation coordinate (after applying the symmetry) can be determined without regard to what cubie is in each position. This type of edge orientation convention was necessary for me to take full advantage of the 48 symmetries of the cube in order to reduce the number of effective cube positions to under 4 billion.
\r\n- Bruce Norskog','65.229.144.203',1122500518,0,0,'1/','a:1:{i:0;i:0;}'),(55,0,26,23,'I doubt that anybody has done','I doubt that anybody has done this particular calcuation before. I certainly haven\'t. It\'s very nice work. Congratulations.\r\n\r\nIt would probably be useful if you could post the symmetry reduced numbers. I usually consider them more significant than then non-reduced numbers because I tend to think in terms of the \"real size\" of cube space rather than the \"group size\".\r\n\r\nIt would also be useful if you could describe a few more details of your program. The search space is pretty large because 1841970x2048 is 3772354560. I think the best you can do is 2 bits per position, storing the distance from Start mod 3, with one other bit pattern indicating that you haven\'t calculated the position yet. At that rate, you would need 943088640 bytes to store all the results, which is about a gigabyte. Were you able to keep all the results in memory, or did you have to use disk? I also assume that you would have to treat the \"times 1841970\" index as sort of an associative array, because the symmetry classes are so ill-behaved. I would assume you would treat the \"times 2048\" index as a bit string, with each bit representing flipped or not. It\'s 2^11 rather than 2^12 because the flip of the first eleven edge cubies dictates the flip of the twelfth cubie.','68.47.230.99',1122525694,0,0,'2/','a:1:{i:0;i:0;}'),(56,54,26,23,'This note is remindful of som','This note is remindful of some messages that appeared on Cube-Lovers. Generally speaking, proofs of the conservation of flip involve \"marking\" one of the two faces of each edge cubie as you describe. I usually refer to such marking as establishing a frame of reference. For each each cubie, it really doesn\'t matter which face you mark as long as you are consistent thereafter. Hence, there are 2^12=4096 possible frames of references in which to describe the flip status of all the edge cubies. Your list (UF,UB,DF,DB,LU,LD,RU,RD,FL,FR,BL,BR) chooses one of the 4096 possible frames of reference.\r\n\r\nOccasionally a proof of conservation of flip is offered that claims not to establish such a frame of reference. It may be only a matter of terminology, but it always seems to me that such proofs really do establish a frame of reference. It\'s just that with some proofs the frame of reference is stated very explicitly, and with other proofs the frame of reference is much more implicit. In particular, a fairly abstract proof for conservation of flip can be given involving a wreath product representation of the edges group, and a wreath product representation makes the frame of reference fairly implicit rather than explicit.\r\n\r\nBut I think the frame of reference always there. The issue is that when an edge cubie is in its home cubicle, it\'s easy to tell if it\'s flipped or not. But if an edge cubie is not in it\'s home cubicle, then you can\'t tell if it\'s flipped or not without a frame of reference.\r\n','198.146.193.166',1122562083,0,0,'1.1/','a:1:{i:0;i:0;}'),(57,55,26,31,'I used less than 2 bits per position in memory, but ...','I was working with a computer with 1GB of memory, so I couldn\'t afford two bits per position in memory, and had to perform some file I/O at the end of each iteration. Here are the details.
\r\n\r\nI figured using two bits for each of the 3,772,354,560 elements would use up too much memory. I needed to find a way to use less than two bits. Packing 5 elements per byte would reduce the memory requirement for this data to less than 755 million bytes. This would mean I would have essentially a ternary digit of storage for each element. That is, each element could have a value of 0, 1, or 2. I came up with a way to make this work, using a 4-bit per element disk file, along with the large RAM array.
\r\n\r\nMy program performs has a main loop that determines the elements at a distance one more than the previous iteration. Each iteration starts with a disk file containing the distances of each of the 3.772+ billion positions (except a distance value of 15 is used for any element for which the distance is still unknown) and the RAM array has all ternary digits being 0 except for those elements that have the maximum distance determined so far. Let\'s say the previous iteration determined the elements at distance d from the solved state. Then, the new iteration takes each element whose array value is 1, and computes all positions one move away (quarter-turn, face-turn, or whatever metric is used), and sets the corresponding array elements to the value 2 (except for those where the existing value was 1). This means the elements with an array value of 2 will be either distance d+1 or d-1 from the solved state. Thus, more \"new\" elements are generated than we really want. This is remedied by using the disk file.
\r\n\r\nAfter all the elements are processed for the iteration, the disk file from the previous iteration is read. If the disk file contains a value other than 15, the distance value is valid and is merely copied to the disk file for this new iteration. If the disk file contains the value 15, then the RAM array is checked. If the RAM array value is 2, the value d+1 is written to the new disk file. We know the distance in this case must be d+1, not d-1; otherwise the old file would have had the distance d-1 for it, and the value d-1 would have been copied to the new file. Also, the RAM array values are fixed up for the next iteration during this processing.
\r\n\r\nIn summary, data for 5 positions were packed into a byte of memory, with the penalty of having to concurrently read one large file and write one large file at the end of each iteration. No random access files were used.
\r\n\r\n- Bruce Norskog','65.229.154.248',1122594033,0,0,'2.1/','a:1:{i:0;i:0;}'),(58,55,26,31,'sym-coordinates and edge orientation coordinates','My program needed to convert between \"raw\" coordinates and sym-coordinates (both directions). I used a procedure analogous to that used in Mike Reid\'s optimal solver program to do that, only I was dealing with 8 corner cubies whereas Mike\'s code was dealing with 4 edge cubies.
\r\n\r\nIn my case, the arrays required over 700 million bytes. This was too much, of course. So I looked for patterns within the arrays, and eventually came up with a way to do the same conversions with 14 lookup tables using a total of about 48 million bytes. This could probably be improved, but I felt it was good enough.
\r\n\r\nAfter verifying my new conversion code produced the same results as the direct conversion tables for all possible values, I could eliminate the direct conversion tables from the program. This provided room for the \"main array\" of the program.
\r\n\r\nYes, my edge orientation coordinate was an 11-bit number with a bit containing a 1 corresponding to a flipped edge. The MSB represented the UF edge position, and the LSB represented the BL edge position. The BR edge position was omitted from the 11-bit number.
\r\n\r\n- Bruce Norskog','65.229.154.248',1122595412,0,0,'2.2/','a:1:{i:0;i:0;}'),(59,55,26,31,'Where are the symmetry-reduced numbers?','My program output contained symmetry-reduced numbers, but the numbers were in relation to the \"coordinate space\" I used. My program did not calculate the \"real\" symmetry-reduced numbers.
\r\n\r\nThere are \"real\" positions that do not map to a unique value in my coordinate space. I put in code to ensure that when a \"new\" position was found, any other position corresponding to the same \"real\" position was also marked \"new.\" So it looks like to me I could have easily have generated the \"real\" symmetry-reduced numbers. It should not be necessary to rerun from scratch to get these numbers, so I think I can do this in the next day or so.
\r\n\r\n- Bruce Norskog','65.229.154.248',1122598246,0,0,'2.3/','a:1:{i:0;i:0;}'),(60,59,26,31,'Symmetry-reduced results','Finally, I have \"real\" symmetry-reduced numbers for the 3x3x3 cube when corner locations and orientations are considered along with edge orientation using (UF,UB,DF,DB,LU,LD,RU,RD,FL,FR,BL,BR) to define the edge orientation reference framework. These results (and the results of my original post) are unconfirmed.
\r\nBy \"real\" symmetry-reduced numbers, I mean that positions that are equivalent under one of the 48 cube symmetries are considered the same position. Anti-symmetry was not considered.\r\n\r\n \"real\" positions cumulative total\r\n\r\nface-turn metric\r\ndistance 0f 1 1\r\ndistance 1f 2 3\r\ndistance 2f 9 12\r\ndistance 3f 73 85\r\ndistance 4f 839 924\r\ndistance 5f 10,100 11,024\r\ndistance 6f 123,829 134,853\r\ndistance 7f 1,490,278 1,625,131\r\ndistance 8f 17,206,529 18,831,660\r\ndistance 9f 177,181,959 196,013,619\r\ndistance 10f 1,268,898,678 1,464,912,297\r\ndistance 11f 2,214,419,000 3,679,331,297\r\ndistance 12f 83,438,084 3,762,769,381\r\ndistance 13f 71 3,762,769,452\r\n\r\nquarter-turn metric\r\ndistance 0q 1 1\r\ndistance 1q 1 2\r\ndistance 2q 5 7\r\ndistance 3q 25 32\r\ndistance 4q 218 250\r\ndistance 5q 1,934 2,184\r\ndistance 6q 17,530 19,714\r\ndistance 7q 156,835 176,549\r\ndistance 8q 1,374,168 1,550,717\r\ndistance 9q 11,364,530 12,915,247\r\ndistance 10q 83,047,697 95,962,944\r\ndistance 11q 477,575,701 573,538,645\r\ndistance 12q 1,483,874,938 2,057,413,583\r\ndistance 13q 1,392,144,562 3,449,558,145\r\ndistance 14q 313,070,169 3,762,628,314\r\ndistance 15q 141,138 3,762,769,452\r\n\r\n- Bruce Norskog','65.229.154.155',1122739488,0,0,'2.3.1/','a:1:{i:0;i:0;}'),(61,0,26,13,'3x3x3 cube ignoring edge locations','How did you store so many configurations ?\r\nThat would need 90Gbytes of storage !\r\nHow long did you take to run all this ?\r\n\r\nHave you considered using this table as a base for\r\nthe heuristic function used IDE-A* search methods?\r\n\r\ngreat work!\r\n\r\nClaude','132.206.3.148',1122924754,0,0,'3/','a:1:{i:0;i:0;}'),(62,61,26,31,'Re: 3x3x3 cube ignoring edge locations','> How did you store so many configurations ?
I used the "coordinate space" of size 1841970*2048 to reduce the number of values stored to 3,772,354,560. This requires about 1.886*(10^9) bytes of disk storage at 4 bits per element. This space uses symmetry in the corner cubies. (Note, the "real" number of positions, using symmetry of the edge orientations as well as the corners, according to brute-force counting by some code I added to the program, appears to be 3,769,762,452.)
\r\n\r\nNote that I used a certain edge orientation convention that allows use of the full 48 symmetries of the cube. Another edge orientation convention might provide a higher average distance, but using fewer symmetries would require a larger table.
\r\n\r\n> How long did you take to run all this ?\r\n\r\nThe face turn metric took about 16h 17m for the main loop to execute (including one extra iteration to verify no new positions were found). The initialization I believe was under 10 minutes. I had optimized the file I/O when I ran the quarter turn metric, and used an internal hard drive instead of an external USB2 drive. It took about 10h 20m to run the first fourteen iterations. (I initially did the quarter-turn metric in two steps, but found that I really didn\'t need to since all the remaining positions were reached in the 15th iteration.) I reran the quarter-turn metric in a single step, but I don\'t seem to have the timing information from that. I think the main reason the quarter-turn metric was faster is that there are only 12 moves instead of 18 to process for each position. (Note: I used a Pentium4, 2.4GHz, 1GB RAM).
\r\n\r\nNote, I am not mentioning time spent to build and save lookup table data that was done prior to the final \"runs\" that produced the results. The final runs loaded some of the lookup tables from disk files.
\r\n\r\n> Have you considered using this table as a base forYes, I am working on incorporating this with some code of mine based roughly on the IDA* pseudo-code I found on Jaap\'s web site. (I am not quite sure if you mean exactly the same thing by IDE-A*.)
\r\n\r\n- Bruce Norskog','65.229.154.194',1122940696,0,0,'3.1/','a:1:{i:0;i:0;}'),(63,0,27,4,'innie or outie','It\'s more than 12 years since I did this stuff, so take what I say next with a hefty dose of scepticism.\r\n\r\n>Are the two definitions equivalent?\r\n\r\nI think so. \r\nFrom your description it is not intuitively obvious that such a GM exists. However, what should be possible is to construct a group with the properties we need.\r\n\r\nWe have the cube group G, and symmetry group M. There is also a group action, where every element of M acts on the set G, in such a way as to preserve its group structure.\r\n\r\nDefine a group H as an external semi-direct product of G and M as follows:\r\nH = { (m,g) | m in M, g in G }\r\nwith the product rule:\r\n(m1,g1)x(m2,g2) = (m1m2, g1^m2\' g2 )\r\n\r\nwhere g1^m2\' is the result of the action of m2\' on g1.\r\nIn actual fact, you can consider g3 to be equal to m2\'g1m2, though that would really be circular reasoning because we haven\'t defined any kind of multiplication between elements of M and of G yet.\r\n\r\nCheck this is associative:\r\n[(m1,g1)x(m2,g2)]x(m3,g3) = (m1m2, g1^m2\' g2 )x(m3,g3) = (m1m2m3, (g1^m2\' g2)^m3\' g3 )\r\n(m1,g1)x[(m2,g2)x(m3,g3)] = (m1,g1)x(m2m3, g2^m3\' g3 ) = (m1m2m3, g1^(m3\'m2\') g2^m3\' g3 )\r\nAnd indeed (g1^m2\' g2)^m3\' = (g1^m2\')^m3\' g2^m3\' = g1^(m3\'m2\') g2^m3\'\r\n\r\nIn this group G is isomorphic to {(e,g)|g in G} and M is isomorphic to {(m,e)|m in M}, both subgroups of this external semidirect product H that we constructed from G and M.\r\n\r\nIf we now identify G and M with those subgroups of H, then we find that H is actually the GM we were looking for, and things become very much simpler. It is at this point that you can see that the product rule use above isn\'t some rabbit pulled out of a hat. If you remove all the comma\'s and brackets, you simply get:\r\nm1g1 m2g2 = m1m2 g3g2\r\nwhere g3 = m2\' g1 m2, an obvious truism that allow us to rewrite any element as a product of an element of M and an element of G.\r\n\r\nInner automorphisms of G are still just conjugations with some fixed element of G, and outer automorphisms of G are now congugations with some element of GM not in G.\r\n\r\nOf course there may be other outer automorphisms of G. If there are further outer automorphisms, then they generate some group which we can use as M in the above construction, and so we find that any outer automorphism of G is an inner automorphism in some supergroup of G.\r\n\r\nJaap\'s Puzzle Page:\r\nhttp://www.geocities.com/jaapsch/puzzles/\r\n','134.146.0.12',1123140565,0,0,'1/','a:1:{i:0;i:0;}'),(64,36,22,30,'Reduction of cube space with GAP','First, I am very new to this, so bear with me while I attempt this:\r\n\r\nI have written the class of symmetries for GAP that can replicate Martin\'s results and the idea can further be applied to other permutation puzzles. (Given the class of symmetries, M) This is merely what Martin wrote in the article http://www.math.rwth-aachen.de/~Martin.Schoenert/Cube-Lovers/Martin_Schoenert__Re__The_real_size_of_cube_space.html with one minor change:\r\n\r\ngap> Sum( ConjugacyClasses( M ),\r\n> c -> Size( Centralizer(G,Representative(c)) ) / Size( M ) * Size(c) );\r\n\r\nIf you would like to see the definitions of M I used I will post them here.\r\n\r\n\r\nI may have an explanation to the question of what GAP did.\r\n\r\nWhat Martin was using is what www.mathworld.com refers to as the Cauchy-Frobenius Lemma.\r\n\r\nIt states this: Let J be a finite group and the image R(J) be a representation which is a homomorphism of J into a permutation group S(X), where S(X) is the group of all permutations of a set X. Define the orbits of R(J) as the equivalence classes under x~y, which is true if there is some permutation p in R(J) such that p(x)=y. Define the fixed points of p as the elements x of X for which p(x). Then the average number of fixed points of permutations R(J) in is equal to the number of orbits of R(J). \r\n\r\nUsing this to enumerate the equivalence classes in GAP would be averaging the sum of the size of the centralizers of each permutation.\r\n\r\nThis lemma was later rediscovered by Burnside as a coloring theorem and is a an application of the Cauchy-Frobenius Lemma.\r\n\r\nIt accounts for all N-colorings by averaging the number of colorings left fixed by each permutation. (N^(number of cycles in permutation))\r\n\r\nI hope I didn\'t confuse anyone with my lack of experience...\r\nQuestions/comments/corrections welcome!\r\n\r\nThank you for your time,\r\n-Joe','131.123.21.74',1123158117,0,0,'1.1.1.3/','a:1:{i:0;i:0;}'),(65,63,27,23,'There are a number of ways to','There are a number of ways to constuct GM, so there is no doubt about its existence. It seems to me that the most straightforward way to construct it is as follows.\r\n\r\nFirst, if Q is the set of quarter turns, then we may simply generate G as G=<Q>.\r\n\r\nSecond, we need generators for M, the group of 48 cube symmetries. Unfortunately, Cube-Lovers never settled on a standard notation for the individual elements of M, so let\'s try the following. We may think of M as C ∪ Cν, where C is the group of 24 cube rotations, and ν is the central inversion. So Cν is the set (not group) of 24 reflections of the cube. We let cr be a 90 degree clockwise rotation of the whole cube centered on the R face, cf be a 90 degree clockwise rotation of the whole cube centered on the F face, etc. \r\n\r\nThis convention only defines a notation for 6 of the 24 rotations, but we only need 2 of them as generators for C. For example, we can generate C as C=<cr,cf> and we can generate M as M=<cr,cf,ν>.\r\n\r\nWith these generators in mind, we can generate GC as GC=<Q,cr,cf> and we can generate GM as GM=<Q,cr,cf,ν>. \r\n\r\nGC can be realized on a physical cube by making standard quarter turns plus rotating the cube as a whole in your hands. GM cannot be realized on a physical cube (at least, not \"really\") because it includes improper symmetries, namely the reflections. But you can realize GM \"virtually\" on a physical cube by holding your physical cube up to a mirror.\r\n\r\nGC is 24 times larger than G, and GM is 48 times larger than G.\r\n\r\nIf you use, for example, an S48 model for the cube, then each of G, GC, and GM is a subgroup of S48. If you use an S24xS24 model for the cube, then each of G, GC, and GM is a subgroup of S24xS24. Etc.\r\n\r\nOf course, your model for GM certainly seems correct as well. And if I am understanding your note properly, your model for for GM provides a convenient framework for proving that any outer automorphism of G is an inner automorphism in some supergroup of G. In other words, for any outer automorphism of G, there exists an element h that is not in G but that is in a supergroup of G such that the automorphism in question may be expressed as G^h.\r\n\r\nJerry\r\n','68.47.230.99',1123216447,0,0,'1.1/','a:1:{i:0;i:0;}'),(66,65,27,4,'What I find difficult about t','What I find difficult about this whole subject is that certain things are so closely related that it is so easy to get confused. In particular:\r\n\r\n
cube positions vs. cube permutations\r\n\r\n
rotations of 3d space applied to a position, vs. 3d rotations applied to a cube permutation\r\n\r\n
With these generators in mind, we can generate GC as GC=<Q,cr,cf>\r\nand we can generate GM as GM=<Q,cr,cf,v>.\r\n\r\n
Here you implicitly assume there is a way to multiply an element of G (or Q) and an element of M (or cr,cf,v). Later on you mention considering them as permutations of the 48 facelets, and in that context the multiplication is indeed obvious.\r\n\r\n
However, it would be better to use S54, i.e. include the centre facelets. Otherwise a 4-spot pattern would be considered the same as a 180 degree cube rotation.\r\n\r\n
Of course, your model for GM certainly seems correct as well. And if I am understanding your note properly, your model for for GM provides a convenient framework for proving that any outer automorphism of G is an inner automorphism in some supergroup of G.\r\n\r\n\r\n
Exactly. That is really the only point of doing it that way.\r\n\r\n
In fact, my model is not much different from yours. I constructed an external semi-direct product, whereas you are constructing an internal semi-direct product. In my case G and M are groups related only by how M acts on G and I construct an external supergroup to contain them. In your case you explicitly state how M acts on G by modelling them internally as subgroups if S54.\r\n\r\n
A nice way to think of this is as follows. GM is really just the set GM = {gm|g in G, m in M}. You need a product rule to make it a group, so you need to know what happens when you multiply the elements g1m1 and g2m2. To get the result g1m1g2m2 to lie in GM, you need to somehow swap m1 and g2. This is where you need to know how M interacts with G.\r\n\r\n
We have for example that cUqF = qRcU, where the q are quarter turns of faces and cU is a quarter cube rotation around the U axis. Any m1 can be \'pulled through\' any g2, and in the process m1 doesn\'t change though g2 does. In other words, m1g2 = g3m1 for some g3 in G. The product rule then becomes\r\n\r\n
g1m1.g2m2 = g1g3.m1m2 where g3= m1g2m1\'.\r\n
(This is slightly different to what I had in the previous post cause I had M and G the other way around).\r\n\r\n
This is where the conjugation comes in, and g3 is simply g2 acted upon by m1 through conjugation. Also G is normal in GM because any element m can be pulled though, mG=Gm.\r\n\r\n
Jaap\'s Puzzle Page:\r\n
http://www.geocities.com/jaapsch/puzzles/','134.146.0.12',1123227821,0,0,'1.1.1/','a:1:{i:0;i:0;}'),(67,0,28,4,'Using GAP and U rotations and','
Using GAP and U rotations and reflections I have come up with a total of 8020.\r\n\r\n
When you say you did U rotations, do you mean you consider two LL perms the same if they differ by a final U turn? Doing only that is not enough. Two algs LL perms may also differ by preceding it by a U turn, and that would reduce your number by a further factor 4 approx.\r\n\r\n
You can consider two LLs equivalent if they are conjugates by a U turn (or a rotation of the whole cube around the U axis, which amounts to the same thing). Together with inversion, that should get you down to 1211 (or maybe 1212 if you count the identity).\r\n\r\n
\r\nJaap\'s Puzzle Page:\r\n
http://www.geocities.com/jaapsch/puzzles/','134.146.0.12',1123228753,0,0,'1/','a:1:{i:0;i:0;}'),(68,0,29,4,'There was a thread on twistyp','There was a thread on twistypuzzles that briefly touched on this:\r\nhttp://twistypuzzles.com/forum/viewtopic.php?t=2270\r\n\r\n
Jaap\'s Puzzle Page:\r\n
http://www.geocities.com/jaapsch/puzzles/','134.146.0.12',1123229275,0,0,'1/','a:1:{i:0;i:0;}'),(69,67,28,30,'Thanks for the response.A','Thanks for the response.\r\n\r\nActually, I should have been more precise than \'U rotations\'. I meant conjugation by rotations of the final layer\'s face. Your original interpretation that I meant permutations that differ only by a face turn was what I was missing!\r\n\r\nThanks again,\r\n-Joe','131.123.21.74',1123243385,0,0,'1.1/','a:1:{i:0;i:0;}'),(70,62,26,31,'Simple optimal solver results','
I have implemented a couple of simple optimal solvers that use the distance table I generated as a pruning table. (I used the face-turn metric distance table, although with a few changes to my code, I should be able to use the quarter-turn metric table.) The good news is that the correct optimal solutions were obtained for the test cases I tried, providing some additional validation to the distance tables. The programs are not any where near the performance needed to compete with optimal solvers already available.
\r\n\r\nThe full distance table has a size in excess of 1.886E+9 bytes (about 1.9 GB), so it is too large to use as is in a computer with 1GB of RAM. I have used a couple of techniques to reduce the amount of memory used for the pruning table.
\r\n\r\nFirst, I used a technique I\'ve experimented with where I used a "perimeter search" in combination with the IDA* algorithm, and a pruning table with reduced information. The second approach used a modulo 3 pruning table.
\r\n\r\nThe first method essentially used an IDA* algorithm, except when the remaining search depth was reduced to a distance of 6, I used a table lookup to determine if the position was actually distance 6 from the solved cube state. This used a totally separate table that was a hash table storing all the positions of the cube of distance 6 (or less) from the solved state. As a result, a pruning table value in the range of 1 to 7 becomes essentially useless. This means I could reduce the pruning table to 3 bits wide (per position) and have the three bits represent the values 0, 8, 9, 10, 11, 12, and 13 with one bit-combination left over. (13 is the maximum value in my table for the face-turn metric.) But this would still require more than 1GB. I wanted to compress 5 pruning table values into a byte, so instead I used the equivalent of one ternary digit to represent only the values 0, 10, and 11. If the value in the original table is 0 to 9, 0 is used. 11 is used for any values of 11 or more in the original table. This unfortunately reduces the effectiveness of the pruning table. The increased memory for the "perimeter table" seemed to be enough to cause the computer to use the computer swap file to some extent, perhaps due to background processes waking up.
\r\n\r\nThe 2nd approach uses a trick mentioned in the documentation of the Cube Explorer program by H. Kociemba. In memory, I store the distance value from the original table modulo 3. With this method, there is no effective loss of information in the pruning table, but the time it takes to determine the actual value is much longer. Generally, many lookups and cube move operations must be performed to arrive at the proper value. See the Cube Explorer documentation for more details on this method. My code for performing a basic move is not currently optimized (it translates a symmetry-reduced representation to a non-symmetry-reduced representation, performs the move in that representation, and then converts back to the symmetry-reduced representation), further increasing the time to calculate the proper pruning table value.
\r\n\r\nThe table below gives a summary of results I obtained using three test cases using cubes of distances 14 to 16 from the solved cube. (The last test case using the second method was not run to completion, but progress information allowed me estimate what the total execution would have been.) It can be seen how the reduced effectiveness of the pruning table in the first method increased the number of nodes generated. The node count would have been much higher without the perimeter search were not employed. However, since the pruning table lookups were much faster with this method, the overall execution time was actually much less than with the second method.
\r\n\r\n(Note: the number of nodes is for the final iteration of the IDA* algorithm, and the final iteration continued to completion after the first solution was found to look for other possible optimal solutions. The execution times were for all iterations. Note that with the first method, a hash table lookup checked if the distance was less than or equal to 6, so the IDA* algorithm started with a search depth of 7.)
\r\n\r\n first method (with perimeter search) second method (with mod 3 table)\r\ndistance nodes execution time nodes execution time\r\n 14 14,017,014 55s 6,305,748 4m 0s\r\n 15 244,926,576 10m 41s 115,281,765 1h 11m 0s\r\n 16 2,848,008,711 2h 03m 36s ? 13h (estimated)\r\n\r\n
The use of a 2nd pruning table that uses edge permutation information would probably help to improve the performance of the program, but for a machine with 1 GB of RAM, there is not a lot of memory to spare.
\r\n- Bruce Norskog','65.229.154.191',1123276034,0,0,'3.1.1/','a:1:{i:0;i:0;}'),(71,0,26,31,'Pruning table comparison','I wrote a small program to simulate performing pruning table lookups for 100 million cube positions, based upon the distribution of the distance values in the table. The program shows the results for the distance table I generated for the face-turn metric as well as the results for the pruning table used in the Huge Optimal Solver in the Cube Explorer program by H. Kociemba. Note that the Cube Explorer program makes use of the pruning table 3 times per position, making that table significantly more effective than if only 1 lookup per position were performed. (The maximum value from the three lookups can be used as the pruning table value.)
\r\n\r\nSo while it calculated the average value for the Huge Optimal Solver pruning table to be about 10.306, the effective value came out to be about 10.804. It is not clear to me whether or not the Huge Optimal Solver in Cube Explorer can and does incorporate a further technique attributed to Michiel de Bondt. If that is the case, my simulation indicates the effective average pruning table value for a cube position increases to 10.991. (The readme file distributed with the program appears to say it\'s only used with the program\'s standard solver, not the huge optimal solver.)
\r\n\r\nThe pruning table I generated that considers the permutation of the corners, and the orientations of both the corners and the edges, comes out to an average distance of approximately 10.575. So although my table has a higher average distance, the pruning table used in the Huge Optimal Solver of the Cube Explorer appears to be somewhat better when you take into account how it is used. (Since Cube Explorer uses the face-turn metric, all numbers are in terms of that metric.)
\r\n\r\nI thought I would make one additional comment here. In the Huge Optimal Solver, the sym-coordinate used related only to edge permutation information (as compared to my program, where two raw cooordinates, corner permutation and corner orientation, are used in creating a sym-coordinate). I assume this greatly simplifies the translation from \"raw\" coordinates to \"sym\" coordinates. I believe if I had used only corner permutation information to create a sym-coordinate, the number of positions for my table would needed to have been 984*2187*2048 = 4,407,312,384, I believe. At 5 positions per byte, the amount of RAM for the main table would have been over 881 million bytes, about 127 million bytes extra, and I suspect it may have been a little too much for the program to run completely from RAM on a 1GB Windows XP machine.
\r\n\r\nFinally, I would like to thank other people for their prior work and articles/documentation that helped me in creating the program, including Mike Reid, Herbert Kociemba, Jaap Scherphuis, and others. Also thanks to Jerry and Claude for their comments.
\r\n- Bruce Norskog','65.229.154.191',1123280971,0,0,'4/','a:1:{i:0;i:0;}'),(72,66,27,23,'S54 vs. S48','However, it would be better to use S54, i.e. include the centre facelets. Otherwise a 4-spot pattern would be considered the same as a 180 degree cube rotation.\r\n\r\nI don\'t think S54 vs. S48 has anything to do with it. Or more correctly, it comes back to your original point about positions vs. permutations. I find the issue confusing on an almost daily basis, and I\'ve been doing this stuff for over 20 years.\r\n
The same thing is true of the 4-spot pattern on a 3x3x3 cube. In a computer or mathematical model, you don\'t need the face centers to tell if the \"numbers are lined up right\". So for a computer model or mathematical model, an S54 model does not contain any information that is not just as available with an S48 model.\r\n\r\n
I still disagree, but I probably just misconstrued what you said.\r\nYes, S48 is enough to fully hold a model of the cube.\r\nBut no, in this model cube rotations cannot be modelled purely as facelet permutations in the same way as moves. Maybe that wasn\'t what you were trying to convey, but that is what your post seemed to indicate.\r\n\r\n
Let me try to explain this.\r\n
S48 models the permutation of facelets. Each facelet obviously has a home location, and when they are in their home locations, you have the identity perm.\r\n\r\n
Any move or move sequence moves the facelets from their home positions, and is therefore a permutation in S48.\r\n\r\n
Any cube rotation however not only moves the facelets, it changes their home locations as well, i.e. is a recolouring. Within the S48 model, you can only do this by conjugation m\'g m where g is the current permutation, and m is the facelet permutation of the cube rotation/reflection. It is this pre-multiplication that in effect re-defines what the home locations are of the facelets that g permutes. \r\n\r\n
To take the 4-spot example, it has the same facelet permutation as a 180 degree cube rotation around a face. Applying the 4 spot perm m to a permution g gives gm (I multiply on the right), whereas applying the cube rotation to g would give m\'gm instead.\r\n\r\n
What I said about using S54 (or S24xS24xS6) was not correct, or at least incomplete. In this model you can let the cube rotations/reflections be ordinary permutations, and apply them just like moves (i.e. no conjugation needed). The extra S6 keeps track of the centre facelet permutation, and thus contains all the info on which cube rotations/reflections have been applied.\r\n\r\n
Unfortunately, as you point out, this model has 48 solved positions. What we really want to use is S54/M, i.e. factor out those cube rotations/reflections at the end.\r\n\r\n
In effect, you save all the pre-multiplications of all the cube rotation/reflection conjugations, and do their combined effect at the end.\r\n\r\n\r\n
Jaap\'s Puzzle Page:\r\n
http://www.geocities.com/jaapsch/puzzles/','134.146.0.12',1123490851,0,0,'1.1.1.1.1/','a:1:{i:0;i:0;}'),(74,0,29,2,'What about memory?','I\'ve never thought seriously about this, but your estimates may well be rather conservative. Remember that the speed of these searches is roughly proportional to the size of the pruning tables that can be used: We shall (probably) be upgrading to computers with much more RAM over the next couple of decades!\r\n\r\nMike','130.88.128.98',1124464542,0,0,'2/','a:1:{i:0;i:0;}'),(75,0,31,23,'Congratulations!\r\n\r\nI\'m curio','Congratulations!\r\n\r\nI\'m curious about the unique antipode. Given that it\'s unique, I would think that symmetry would require that the antipode be the central inversion on both the corners and the edges. Which is to say, it must be the case that for the antipode x to be unique, it must be the case that Symm(x)=M. And when twists and flips are ignored, the identity and the central inversion are the only permutations for which Symm(x)=M.\r\n\r\nThe Pons Asinorum is an example of the central inversion of the edges, but it is only 12q from Start. The only other cases for the entire cube (when twists and flips are taken into account) where Symm(x)=M are the identity, Superflip, and the composition of Superflip with the Pons Asinorum. But when you ignore twists and flips, Superflip is 0q from Start, rather than being 24q from Start. Therefore, the corners have to be involved in an antipode that is 18q from Start.\r\n\r\nI suppose that the unique antipode could be the permutation that is the central inversion on the corners and which fixes the edges, but the central inversion of both the corners and the edges seems more likely.\r\n\r\nNote that when twists are taken into account, there is no permutation on the corners for which Symm(x)=M. The twists mess up the symmetry of the central inversion. But with the twists not considered, the symmetry of the central inversion on the corners really is Symm(x)=M.\r\n','68.47.230.99',1128283696,0,0,'1/','a:1:{i:0;i:0;}'),(76,75,31,31,'Re: Congratulations! I\'m curio','> I\'m curious about the unique antipode. Given that it\'s unique,\r\n> I would think that symmetry would require that the antipode be\r\n> the central inversion on both the corners and the edges. Which\r\n> is to say, it must be the case that for the antipode x to be\r\n> unique, it must be the case that Symm(x)=M. And when twists and\r\n> flips are ignored, the identity and the central inversion are\r\n> the only permutations for which Symm(x)=M.\r\n\r\nYes, the antipode is the permutation that is the central inversion on both the corners and the edges.\r\n\r\n> I suppose that the unique antipode could be the permutation\r\n> that is the central inversion on the corners and which fixes\r\n> the edges, but the central inversion of both the corners and\r\n> the edges seems more likely.\r\n\r\nI also looked up the distance for the permutation that is the central inversion on the corners and which fixes the edges. It is at distance 14.\r\n\r\n - Bruce Norskog\r\n','63.40.66.157',1128305088,0,0,'1.1/','a:1:{i:0;i:0;}'),(77,0,30,1,'Extending Thistlethwaite\'s algorithm to 4x4x4','I haven\'t crunched the numbers but maybe the next step for 4x4x4 calculations would be extending thistlethwaite\'s algorithm, slice turns instead of face turns. Another idea is calculating God\'s Algorithm for the 4x4x4 squares group. \r\n\r\nMark ','127.0.0.1',1131541475,0,0,'1/','a:1:{i:0;i:0;}'),(78,0,31,31,'Local Maxima','
I have now completed what I hope is an accurate counting of the number of local maximum positions in the quarter-turn metric for the 3x3x3 cube considering the permutations, but not the orientations of the cubies. See the table below for the results.
\r\nThe \"positions\" columns gives the total number of local maxima (not taking any symmetry into account). My program used symmetry in the corner cubies to reduce the effective number of positions to 984 * 12! / 2. I included the local maximum counts for this case in the \"reduced\" column in the table below. Finally, the \"unique wrt M\" column gives the number of local maxima counting only positions that are distinct with respect to the 48 symmetries of the cube. (While the \"reduced\" column considers symmetry of the corners, the \"unique wrt M\" column considers symmetry of both corners and edges.) For reference, the total positions for each case is listed at the bottom.
\r\n\r\nLocal Maxima, QTM, 3x3x3 permutations of corners and edges\r\n(orientations ignored)\r\n\r\ndistance positions reduced unique wrt M\r\n 0 0 0 0\r\n 1 0 0 0\r\n 2 0 0 0\r\n 3 0 0 0\r\n 4 0 0 0\r\n 5 0 0 0\r\n 6 0 0 0\r\n 7 0 0 0\r\n 8 0 0 0\r\n 9 0 0 0\r\n 10 98 13 7\r\n 11 240 16 8\r\n 12 35,380 2,027 858\r\n 13 9,630,276 248,572 201,132\r\n 14 35,533,090,748 895,464,957 740,307,100\r\n 15 1,833,521,581,740 44,697,740,880 38,198,634,121\r\n 16 3,517,318,269 83,693,410 73,289,416\r\n 17 208 22 10\r\n 18 1 1 1\r\n ----------------- -------------- --------------\r\n 1,872,581,656,960 45,677,149,898 39,012,432,653\r\n\r\n total positions (not just local maxima):\r\n 9,656,672,256,000 235,668,787,200 201,181,803,792\r\n\r\n - Bruce Norskog','151.204.237.18',1131739814,0,0,'2/','a:1:{i:0;i:0;}'),(79,0,33,31,'Re: Solving Rubik\'s cube in 40 quarter turns','
Good work! I knew the upper bound of 42 couldn\'t stand too much longer with computer power available nowadays.
\r\n\r\nAnd it should be easy to show that all 44089920 cube positions corresponding to the antipode of the edges-only analysis can all be solved in 39 moves or less. That would further reduce the QTM upper bound to 39. (All non-antipode positions of the edges-only case are solveable for the edges in 17 moves or less. Then assuming your analysis that 22 moves are sufficient for edges-solved positions, all these \"edges-only non-antipode\" positions can also be solved in 39 (17+22) quarter turns.)
\r\n\r\nThis could be taken one step further considering all the positions of distance 17 and 18 in the edges-only analysis. Showing that these can all be solved in 38 quarter turns, then you would have that all cube positions can be solved in 38 quarter turns. (16+22=38) This, of course, means finding out what the three (unique wrt M) positions of distance 17 are. One of them is easily found knowing the antipode. The other two, well, hopefully someone knows what they are.
\r\n\r\nI was looking at doing something similar, but using my (unverified) analysis for the corner+edge permutations. I believe I was able to verify that all cube positions corresponding to the antipode for the permutations were all solveable in less than 42 moves. I was planning to try to verify that all cube positions corresponding to those of distance 2 or less in the permutations-only analysis (not more than 7*2048*2187 positions needing to be checked) could be solved in 26 quarter turns or less. I was unsuccessful at creating a solver that was fast enough to accomplish that in a reasonable time frame. That would have shown that 26+(17-2) = 41 is an upper bound in the QTM (assuming the validity of my permutations-only analysis, of course). Your result is 1 quarter turn better than what I was shooting for.
\r\n\r\nIt makes me wonder what you were using for a cube solver, and what type of computer resources you had available to do the work.
\r\n - Bruce Norskog','70.19.207.253',1132008744,0,0,'1/','a:1:{i:0;i:0;}'),(80,79,33,34,'I hope you are going to do th','I hope you are going to do the 38 computation so that we are going to have a better upper bound. Now about the solver and the resources:\r\n\r\nThe program was made in GAP and takes about 70 days on an usual PC.\r\nBut it is constructed so that if you have N PC computers then the speed is 70/N days. I used 20 computers for about 3-4 days. The program uses following idea:\r\nCall the set of elements that must be computed in 22q or less for X.\r\nRather then concentrating on each position it is better just to generate elements in X regardless to what they are and keep track on which elements have been found. Using this method the program computes all but 105000 positions(of the total 44 milions) in just 1 day on an usual PC. Because we dont have control over what positions we generate in the set X some positions are going to be regenerated and the speed decreases as more positions are found.\r\n\r\nHow are positions in X generated?\r\n\r\nLet (x,y) denote an element in the cube group and x is the edge configruation and y is the corner configuration.Given a fixed edge configuration call it g. Call the set consisting of elements of the form (g,z) achivable in 10 moves or less for S_1. And the set of elements of the form (g^-1,u) achivable in 12 moves or less for S_2. It is obvious that if we take an element from S_1 and multiply by an element from S_2 we get an element of the form (id,uw). For example if we take g to be the identity (of the edge configuration) we get 3079007 elements in X in just 2 minutes after taking all possible products between S_1 and S_2.\r\n\r\nThe above computation have been done very recently and work i still done on the paper presenting detailed algorithms etc. I found however a new algorithm based on the above idea that finishes the 70 day computation in maybe 1-2 days maximum. \r\n\r\nI hope somebody takes the time to verify my \"Data file\". If you do this please send me an email.\r\n\r\nSilviu\r\n','213.112.65.27',1132064164,0,0,'1.1/','a:1:{i:0;i:0;}'),(81,0,24,34,'Hi,\r\n\r\nI use following genera','Hi,\r\n\r\nI use following generators for the cube:\r\n\r\nU:=(1,2,4,8)(6,11,17,22)(25,26,29,36)(27,31,38,45)(33,40,46,44);\r\nL:=(3,6,12,20)(8,15,14,19)(25,27,32,42)(28,31,40,47)(35,41,46,36);\r\nF:=(4,9,16,12)(15,22,18,23)(27,33,43,35)(29,37,32,40)(36,45,39,47);\r\nR:=(2,5,10,18)(9,17,13,21)(26,30,39,33)(29,38,34,43)(37,45,44,48);\r\nB:=(1,3,7,13)(5,11,19,24)(25,28,34,44)(26,31,41,48)(30,38,46,42);\r\nD:=(7,14,16,10)(20,23,21,24)(28,35,37,30)(32,39,34,41)(42,47,43,48);\r\n\r\nAnd for the group of M-symmetries:\r\n\r\nk1:=(1,24,16,22)(2,19,10,15)(3,21,12,17)(4,11,7,23)(5,14,18,8)(6,13,20,9)\r\n(25,48,32,45)(26,41,39,36)(27,44,42,37)(28,43,40,38)(29,31,34,47)(30,35,33,46);\r\nk2:=(1,5,7,19)(2,10,14,8)(3,11,13,24)(4,18,16,15)(6,17,21,20)(9,23,12,22)\r\n(25,44,34,28)(26,48,41,31)(27,33,43,35)(29,37,32,40)(30,42,46,38)(36,45,39,47);\r\n\r\nSilviu','213.112.65.27',1132074929,0,0,'1/','a:1:{i:0;i:0;}'),(82,80,33,31,'Claim that 39 quarter turns are sufficient','As Silviu mentioned, it was recently determined that the cube restricted to edges can be solved in at most 18 quarter turns. Further, that analysis indicated that there is a unique antipode in that case. There are only four configurations of the edges that have this level of symmetry. These configurations can be stated in terms of certain representative positions of the cube where the corners are all in place and oriented correctly. These four cases are:
\r\n1. the solved cube (obviously not the antipode)
\r\n2. Pons Asinorum (solveable in 12 quarter turns: U2 B2 F2 B2 L2 R2, so it can\'t be the antipode)
\r\n3. the superflip
\r\n4. Pons Asinorum composed with the superflip
\r\n\r\n
Since edge configurations corresponding to 1 and 2 can not be antipode, the antipode must correspond to one of the other two edge configurations: the edge configuration of the superflip, or that of Pons Asinorum composed with the superflip.
\r\n\r\nFor each edge configuration, there are 8!*(3^7)/2 = 44,089,920 possible configurations of the corners. I have used a fast cube solving routine to check all cube positions with the same edge configurations as 3 and 4 above. This resulted in finding a way to solve each of these 2 * 44,089,920 cube positions in no more than 38 moves. (Note these solutions that were found are typically far from optimal solutions.) The following tables list the distribution of the lengths (quarter turns) of the solutions that this fast solver found for the set of positions of interest.
\r\n\r\n\r\nSuperflip edge configuration\r\n\r\nsolution\r\nlength count\r\n 14 2\r\n 18 57\r\n 20 177\r\n 22 2835\r\n 24 21714\r\n 26 151834\r\n 28 953099\r\n 30 4649674\r\n 32 13820528\r\n 34 17381839\r\n 36 7107953\r\n 38 208\r\n --------\r\n 44089920\r\n\r\nPons Asinorum composed with superflip edge configuration\r\n\r\nsolution\r\nlength count\r\n 18 40\r\n 20 332\r\n 22 2846\r\n 24 22176\r\n 26 153416\r\n 28 963499\r\n 30 4656631\r\n 32 13817591\r\n 34 17408560\r\n 36 7064629\r\n 38 200\r\n --------\r\n 44089920\r\n\r\n\r\n
Since solutions for cube positions with the superflip edge configuration were found using only 14 quarter turns, the antipode (requiring 18 quarter turns to solve the edges) must be the other edge configuration, corresponding to Pons Asinorum composed with the superflip.
\r\n\r\nNow, divide all positions of the Rubik\'s cube into two sets. The first set being all those with the same edge configuration as Pons Asinorum composed with the superflip. The second set being all the remaining positions.
\r\n\r\nIn the first set, my fast solver found a solution for every case using no more than 38 quarter turns.
\r\n\r\nIn the second set, all positions can reach a configuration with the edges solved in 17 quarter turns or less. According to Silviu\'s result, it takes no more than 22 additional quarter turns to solve the cube, for a total of 17+22 = 39.
\r\n\r\nThus, assuming there are no flaws in any of the computer analyses involved, then all positions of Rubik\'s cube can be solved with no more than 39 quarter turns. I will plan to generate a list of actual quarter-turn sequences to solve the various positions corresponding to the antipode of the edges-only analysis.
\r\n\r\nThe edges-only analysis listed 30 positions that require 17 quarter turns to solve the edges, but only 3 that are unique with respect to M, the symmetry group of the cube. If all cube positions having these edge configurations can be shown to be solved in 38 moves or less (and these require an odd number of moves to solve, so really 37 or less), then that would further reduce the upper bound for the quarter turn metric to 38 (assuming the correctness of the computer analyses used). One of these three positions must be the position one quarter-turn from the antipode. I can\'t check the other two positions unless I can find out what they are.
\r\n - Bruce Norskog','70.19.249.215',1132213671,0,0,'1.1.1/','a:1:{i:0;i:0;}'),(83,82,33,2,'Congratulations to you both -','Congratulations to you both -- this is quite a leap from 42, especially if 38 can be proved.\r\n\r\nTwo questions:\r\n\r\n(1) Do you think this approach would be likely to improve the upper bound in HTM, too? (I suspect not, from the known edges-only result.)\r\n\r\n(2) What kind of fast solver are you using, Bruce?\r\n\r\nMike G.','130.88.128.98',1132303539,0,0,'1.1.1.1/','a:1:{i:0;i:0;}'),(84,83,33,31,'Re: Congratulations to you both','Mike G. wrote:\r\n(1) Do you think this approach would be likely to improve the upper bound in HTM, too? (I suspect not, from the known edges-only result.)\r\n
Lowering the upper bound in QTM from 42 to 38 would bring the upper bound/lower bound ratio close to the same value as for HTM. So I suspect this approach may not yield a better upper bound for HTM. Solving corners without preserving edges takes 11 face turns in the worst case. 14 + 11 = 25, which is fairly close to 28 already. Also the edges-only analysis for HTM has many more antipodes, 24 unique wrt M rather than 1, and one level closer has close to 7 million positions (unique wrt M). So my technique of \"eliminating\" those cases would at least be more time-consuming.
\r\n\r\n(2) What kind of fast solver are you using, Bruce?\r\n
My fast solver is actually a function that I call repeatedly from within a program that is edited and recompiled each time I want to try different cases. It is based somewhat upon the documentation of Herbert Kociemba\'s Cube Explorer two-phase algorithm, but mine builds tables for QTM rather than HTM. My code uses two large arrays of approximately 70MB and 670MB, so distances of positions for each phase can be looked up directly, rather than using an IDA*-like algorithm to solve each phase. The code starts with the position to be solved and looks for a move that will bring it to a closer position. (It doesn\'t look for alternate possible moves once it finds one.) When phase 1 is completed, it does the same for phase 2. Then it eliminates redundant moves from the result. Finally, the whole process is repeated for two other symmetrically equivalent positions to see if a better solution is found. (In obtaining my previously posted results, I stopped the process of trying alternative symmetrically equivalent positions when I found one less than 38 moves. Thus, I eliminated the second and third cases most of the time, providing essentially an average 3x speed improvement.)
\r\n\r\nI have since re-run my program to generate a file with solve sequences for each position. Actually, I put in code so that only one of each set of symmetrically equivalent positions are solved. Since many fewer positions then needed to be analyzed, I changed the code back to always trying three cases for each position, to get shorter average solutions, and a somewhat smaller output file. The file size is approximately 31MB if I use a one-character code for each quarter turn move (or about 38MB if standard notation with apostrophes is used). I can email either file to someone, if requested to do so.
\r\n - Bruce Norskog','70.22.158.136',1132338382,0,0,'1.1.1.1.1/','a:1:{i:0;i:0;}'),(85,0,33,34,'Verification of my \"Data file\"','Bruce sent me a mail in which he showed that the \"Data file\" is correct i.e. it contains all possible moves in 22q or less.\r\n\r\nThanks a lot,\r\nBruce\r\n\r\nPS Bruce i tried to reply your mail but the server returned it.Maybe you can check why.','213.112.65.27',1132433864,0,0,'2/','a:1:{i:0;i:0;}'),(86,0,34,31,'a confirmation of 39 quarter turns as an upper bound','Silviu has informed me that he has verified my set of solutions for covering all the cases for the Pons Asinorum composed with superflip edge configuration. This provides one independent confirmation that all \"legal\" cube positions can be solved in 39 quarter turns or less. (I have confirmed Silviu\'s solutions of 22 quarter turns or less for the identity edge configuration, and he has confirmed my solutions of 38 quarter turns or less for the Pons Asinorum composed with superflip edge configuration.) I do not have independent confirmation at this time for the additional cases needed to confirm 38 as an upper bound.
\r\n\r\nWell, for the record, I am not personally aware if there is an independent verification of the edges-only analysis done by Tomas Rokicki. The claims being made of 40, 39, or 38 as an upper bound depend upon that analysis being correct. I may attempt to perform an independent verification of that analysis myself.
\r\n\r\n - Bruce Norskog','151.204.247.74',1133298386,0,0,'1/','a:1:{i:0;i:0;}'),(87,0,35,2,'Great to see this follow-up t','Great to see this follow-up to your original Cube Lovers post (28 May 96) where you mentioned the reduction that was possible via cyclic permutation of the side colours of the U and D layers. I felt sorely tempted to try the calculation after reading that, so will be very interested to see some more details when they\'re available! \r\n\r\nMike G.','130.88.128.98',1134039840,0,0,'1/','a:1:{i:0;i:0;}'),(88,86,34,31,'confirmation of 38 quarter turns as an upper bound','Silviu has confirmed my solutions for all the cube positions having the edge configurations corresponding to the two local maximum positions of distance 17 in the edges-only (technically edges plus centers) analysis that was done by Tomas Rokicki. There is one other position (unique wrt M) in that edges-only analysis that is not a local maxima. This position is one quarter turn away from the antipode position, of course. Silviu and I have also each determined that all cube positions with the edge configuration corresponding to the antipode of the same edges-only analysis can all be solved in 36 quarter turns are less. (There were just 7 cases where my original solutions were of length 38, and we found shorter solutions for these cases.) Thus, the cube positions with the edge configuration corresponding to this non-local-maximum position of the edges-only analysis can all be solved in no more than 37 quarter turns (since we could make one quarter turn to reach the antipode position for the edges, and then still solve in 36 quarter turns).
\r\n\r\nI have also completed an independent analysis to verify the results of Tomas Rokicki\'s analysis for the edges in the quarter-turn metric. I have verified the number of cube positions is correct for each distance, and also the number of cube positions that are unique wrt M for each distance. In particular, I have verified the 3 positions (unique wrt M) of distance 17 in the edges only analysis that I found previously, are in fact the only positions of that distance. I should soon also have a verification of the number of positions unique wrt M+inv for each distance.
\r\n\r\nIn summary, I have verified Tomas Rokicki\'s analysis of edges-only in the quarter-turn metric. I have also verified Silviu\'s solutions of 22 quarter turns maximum for solving corners without affecting edges. And Silviu has confirmed my results that all cube positions with an edge configuration corresponding to those of distance 17 or higher in the edges-only analysis can be solved in 38 (actually 37) quarter turns or less. Thus, we have at least one independent confirmation of each of the analyses we have used in showing that Rubik\'s cube can always be solved in 38 quarter turns or less.
\r\n\r\nI have also determined the 750 positions (unique wrt M) of distance 16 in the edges-only analysis. Solving all cube positions with these edge configurations could be used to further reduce the upper bound for the quarter-turn metric to 37, but that has not been done yet.
\r\n - Bruce Norskog','70.19.245.5',1135020003,0,0,'1.1/','a:1:{i:0;i:0;}'),(89,0,35,35,'Of course, 7 flips is best for parity fix for Square One','Jaap pointed me to an odd parity fix solution with 7 flips on his site that I had previously overlooked. Alas, it is so obvious, too, once you see it done. Since he has already put all his favorite positions and moves through the optimal solver, my calculation can\'t improve on those results. But I can however, report the counting results for the God\'s Algorithm calculation I mentioned in my previous post... See next post.','216.64.59.154',1135193282,0,0,'2/','a:1:{i:0;i:0;}'),(90,0,35,35,'God\'s algorithm counts','Here are the god\'s algorithm count results for Square One by depth.\r\n\r\n1\r\n64\r\n1153\r\n17050\r\n235144\r\n3091458\r\n38893230\r\n452031138\r\n4459167504\r\n33671064770\r\n149502310936\r\n183662070768\r\n63945120032\r\n157452752\r\n------------\r\n435891456000 \r\n\r\nFor the hard core, I have also included a lising by shape (c=corner, e=edge, format=topshape/bottomshape) and depth at the bottom of this posting. Totals are given first for each shape, and reflect the symmetry degeneracies. i.e. Total positions = 8!*8!*2*((4+1/2)*(1/6)*2+(9+1/3)*3*2+(8+1/2+1/4)*(8+1/2+1/4)) = 435891456000. Will someone please explain to me (Mike G., this means you, as Jaap claims you have a proof on his website) why this is exactly 15!/3? \r\n\r\nNote that the flipped state of the center piece was taken into account, and it is determined solely by whether you are at an odd or even depth.\r\n\r\nOne interesting note is that only a very few shapes are unrepresented at the maximum depth of 13. I was hoping for a handful of antipodes, but instead almost every shape is represented, and square/square is rather more underrepresented than some of the others (like kite/kite (one off start shape)). Perhaps if I had accounted for face turns like Jaap and Mike G. do in their optimal solver, instead of just flips, but that requires about another 5-10 years of Moore\'s Law to kick in before I can do that one, since it will require much more space and computing power.\r\n\r\nAs it was, this calculation took over a year on my old slow computer (800 MHz) and even slower hard drive. I also did not have access to or expertise in a programming language that accesses RAM memory directly - no matter what I did, the program I used always seemed to go to disk to read variables that should have, in theory, fit just fine in the available memory. The program intends to accomplish this by only keeping 2 shapes active at a time, requiring only 200MB of memory and relatively rare loads/unloads, instead of needing random access to the full complement of 170 100MB (4 bits/position) shape files. But as I said, I couldn\'t get my machine to do it in practice.\r\n\r\nI realize also after the fact that I could have taken advantage of another factor of 2 in at least space savings by noting the degeneracy of the top/bottom starting position (instead of just the factor of 16 I utilized from free top/bottom rotations of the start position), but I do not think it would have saved much calculation time, since it would have been more computationally expensive to keep swapping the pieces around artificially all the time instead of just saving the redundant positions to disk. This is also why all the shape files are the same size, each redundant by a factor equal to its symmetry degeneracy - it takes more space, but it is computationally more efficient and definitely easier to program.\r\n\r\nPerhaps I will take advantage of the extra factor of 2 (really 170/90) when I convert the full tables into smaller ones (it will be quite easy to put 5 positions in 8 bits using just depth mod 3, sufficient for retrieving an optimal solution for any position given). So in theory, I could get the entire set of tables down to 3.4 GB in this manner, small enough for a DVD.\r\n\r\nThat\'s enough rambling. If you\'re still with me, here are the full set of counts by shape and depth (in no particular order, but I have kept all top/bottom bottom/top redundant pairs together for clarity):\r\n\r\ncceeeeeeee/cccccc: 541900800 0 0 0 0 64 2048 43008 735936 10145984 88956960 244998048 181255424 15763296 32\r\ncccccc/cceeeeeeee: 541900800 0 0 0 0 64 2048 43008 735936 10145984 88956960 244998048 181255424 15763296 32\r\nceceeeeeee/cccccc: 541900800 0 0 0 0 0 0 960 43040 1152320 21737184 181502048 249156800 88295072 13376\r\ncccccc/ceceeeeeee: 541900800 0 0 0 0 0 0 960 43040 1152320 21737184 181502048 249156800 88295072 13376\r\nceeceeeeee/cccccc: 541900800 0 0 0 0 64 1664 34560 647552 9684672 89058912 247442336 181242272 13788768 0\r\ncccccc/ceeceeeeee: 541900800 0 0 0 0 64 1664 34560 647552 9684672 89058912 247442336 181242272 13788768 0\r\nceeeeceeee/cccccc: 270950400 0 0 0 0 64 1856 33728 515392 6555968 52421920 124122336 82536032 4763104 0\r\ncccccc/ceeeeceeee: 270950400 0 0 0 0 64 1856 33728 515392 6555968 52421920 124122336 82536032 4763104 0\r\nceeeeeceee/cccccc: 541900800 0 0 0 0 0 0 608 43424 1248896 23491392 188124736 247407552 81576160 8032\r\ncccccc/ceeeeeceee: 541900800 0 0 0 0 0 0 608 43424 1248896 23491392 188124736 247407552 81576160 8032\r\nccceeeeee/cccccee: 3251404800 0 0 0 0 128 6656 181632 3600576 53828992 491939328 1451892352 1130155776 119799296 64\r\ncccccee/ccceeeeee: 3251404800 0 0 0 0 128 6656 181632 3600576 53828992 491939328 1451892352 1130155776 119799296 64\r\ncceeceeee/cccccee: 3251404800 0 0 0 0 192 8448 215168 4114496 59773216 525977344 1461192192 1095602048 104521632 64\r\ncccccee/cceeceeee: 3251404800 0 0 0 0 192 8448 215168 4114496 59773216 525977344 1461192192 1095602048 104521632 64\r\ncceeeceee/cccccee: 3251404800 0 0 0 0 0 960 35776 825536 14833920 204015872 1232710208 1420843584 378122496 16448\r\ncccccee/cceeeceee: 3251404800 0 0 0 0 0 960 35776 825536 14833920 204015872 1232710208 1420843584 378122496 16448\r\ncceeeecee/cccccee: 3251404800 0 0 0 0 192 8448 215168 4114496 59773216 525977344 1461192192 1095602048 104521632 64\r\ncccccee/cceeeecee: 3251404800 0 0 0 0 192 8448 215168 4114496 59773216 525977344 1461192192 1095602048 104521632 64\r\ncceeeeece/cccccee: 3251404800 0 0 0 0 64 1664 38016 766080 13279776 185485024 1185556960 1439389632 426827584 60000\r\ncccccee/cceeeeece: 3251404800 0 0 0 0 64 1664 38016 766080 13279776 185485024 1185556960 1439389632 426827584 60000\r\ncececeeee/cccccee: 3251404800 0 0 0 0 128 5760 129472 2219072 32027392 348255232 1414301696 1275221952 179243712 384\r\ncccccee/cececeeee: 3251404800 0 0 0 0 128 5760 129472 2219072 32027392 348255232 1414301696 1275221952 179243712 384\r\nceceeceee/cccccee: 3251404800 0 0 0 0 0 1920 56992 1140416 18574560 232922240 1259614272 1391600832 347456576 36992\r\ncccccee/ceceeceee: 3251404800 0 0 0 0 0 1920 56992 1140416 18574560 232922240 1259614272 1391600832 347456576 36992\r\nceceeecee/cccccee: 3251404800 0 0 0 0 0 1920 56992 1140416 18574560 232922240 1259614272 1391600832 347456576 36992\r\ncccccee/ceceeecee: 3251404800 0 0 0 0 0 1920 56992 1140416 18574560 232922240 1259614272 1391600832 347456576 36992\r\nceceeeeec/cccccee: 3251404800 0 0 0 0 64 1664 38016 766080 13279776 185485024 1185556960 1439389632 426827584 60000\r\ncccccee/ceceeeeec: 3251404800 0 0 0 0 64 1664 38016 766080 13279776 185485024 1185556960 1439389632 426827584 60000\r\nceeceecee/cccccee: 1083801600 0 0 0 0 256 7808 148992 2308800 28885888 220537216 495417984 319046976 17447680 0\r\ncccccee/ceeceecee: 1083801600 0 0 0 0 256 7808 148992 2308800 28885888 220537216 495417984 319046976 17447680 0\r\nccceeeeee/ccccece: 3251404800 0 0 0 0 0 384 16768 436800 8685248 136291328 1058548864 1488706304 558451520 267584\r\nccccece/ccceeeeee: 3251404800 0 0 0 0 0 384 16768 436800 8685248 136291328 1058548864 1488706304 558451520 267584\r\ncceeceeee/ccccece: 3251404800 0 0 0 0 0 1536 50336 1046336 17396800 222208032 1236014464 1402378272 372240800 68224\r\nccccece/cceeceeee: 3251404800 0 0 0 0 0 1536 50336 1046336 17396800 222208032 1236014464 1402378272 372240800 68224\r\ncceeeceee/ccccece: 3251404800 0 0 0 0 128 3328 68864 1175232 17354752 209394368 1209565760 1415087808 398712896 41664\r\nccccece/cceeeceee: 3251404800 0 0 0 0 128 3328 68864 1175232 17354752 209394368 1209565760 1415087808 398712896 41664\r\ncceeeecee/ccccece: 3251404800 0 0 0 0 0 1536 50336 1046336 17396800 222208032 1236014464 1402378272 372240800 68224\r\nccccece/cceeeecee: 3251404800 0 0 0 0 0 1536 50336 1046336 17396800 222208032 1236014464 1402378272 372240800 68224\r\ncceeeeece/ccccece: 3251404800 0 0 0 0 64 2944 68928 1250016 18988928 224473344 1203811232 1399802624 402833248 173472\r\nccccece/cceeeeece: 3251404800 0 0 0 0 64 2944 68928 1250016 18988928 224473344 1203811232 1399802624 402833248 173472\r\ncececeeee/ccccece: 3251404800 0 0 0 0 128 4608 106112 1907840 28616064 322969920 1389881792 1300818944 207098304 1088\r\nccccece/cececeeee: 3251404800 0 0 0 0 128 4608 106112 1907840 28616064 322969920 1389881792 1300818944 207098304 1088\r\nceceeceee/ccccece: 3251404800 0 0 0 0 512 13824 246688 3626528 45010688 395918592 1321531072 1226080672 258913440 62784\r\nccccece/ceceeceee: 3251404800 0 0 0 0 512 13824 246688 3626528 45010688 395918592 1321531072 1226080672 258913440 62784\r\nceceeecee/ccccece: 3251404800 0 0 0 0 512 13824 246688 3626528 45010688 395918592 1321531072 1226080672 258913440 62784\r\nccccece/ceceeecee: 3251404800 0 0 0 0 512 13824 246688 3626528 45010688 395918592 1321531072 1226080672 258913440 62784\r\nceceeeeec/ccccece: 3251404800 0 0 0 0 64 2944 68928 1250016 18988928 224473344 1203811232 1399802624 402833248 173472\r\nccccece/ceceeeeec: 3251404800 0 0 0 0 64 2944 68928 1250016 18988928 224473344 1203811232 1399802624 402833248 173472\r\nceeceecee/ccccece: 1083801600 0 0 0 0 0 0 4096 133504 2831936 45162816 352244736 496498688 186820032 105792\r\nccccece/ceeceecee: 1083801600 0 0 0 0 0 0 4096 133504 2831936 45162816 352244736 496498688 186820032 105792\r\nccceeeeee/cccecce: 3251404800 0 0 0 0 0 512 16384 355520 6416704 94343808 811189184 1523908416 808080128 7094144\r\ncccecce/ccceeeeee: 3251404800 0 0 0 0 0 512 16384 355520 6416704 94343808 811189184 1523908416 808080128 7094144\r\ncceeceeee/cccecce: 3251404800 0 0 0 0 64 2016 41024 709376 10812960 136104576 928514272 1483515584 686334080 5370848\r\ncccecce/cceeceeee: 3251404800 0 0 0 0 64 2016 41024 709376 10812960 136104576 928514272 1483515584 686334080 5370848\r\ncceeeceee/cccecce: 3251404800 0 0 0 0 0 384 19968 566912 11604928 167762688 1065406144 1456606080 548671360 766336\r\ncccecce/cceeeceee: 3251404800 0 0 0 0 0 384 19968 566912 11604928 167762688 1065406144 1456606080 548671360 766336\r\ncceeeecee/cccecce: 3251404800 0 0 0 0 64 2016 41024 709376 10812960 136104576 928514272 1483515584 686334080 5370848\r\ncccecce/cceeeecee: 3251404800 0 0 0 0 64 2016 41024 709376 10812960 136104576 928514272 1483515584 686334080 5370848\r\ncceeeeece/cccecce: 3251404800 0 0 0 0 0 768 29792 689056 12301536 164059072 1040801344 1459679264 572569728 1274240\r\ncccecce/cceeeeece: 3251404800 0 0 0 0 0 768 29792 689056 12301536 164059072 1040801344 1459679264 572569728 1274240\r\ncececeeee/cccecce: 3251404800 0 0 0 0 0 128 11392 333824 6702720 103537856 881996160 1519426624 736992128 2403968\r\ncccecce/cececeeee: 3251404800 0 0 0 0 0 128 11392 333824 6702720 103537856 881996160 1519426624 736992128 2403968\r\nceceeceee/cccecce: 3251404800 0 0 0 0 0 1472 41600 808512 12832576 158333312 989377312 1462481952 623450912 4077152\r\ncccecce/ceceeceee: 3251404800 0 0 0 0 0 1472 41600 808512 12832576 158333312 989377312 1462481952 623450912 4077152\r\nceceeecee/cccecce: 3251404800 0 0 0 0 0 1472 41600 808512 12832576 158333312 989377312 1462481952 623450912 4077152\r\ncccecce/ceceeecee: 3251404800 0 0 0 0 0 1472 41600 808512 12832576 158333312 989377312 1462481952 623450912 4077152\r\nceceeeeec/cccecce: 3251404800 0 0 0 0 0 768 29792 689056 12301536 164059072 1040801344 1459679264 572569728 1274240\r\ncccecce/ceceeeeec: 3251404800 0 0 0 0 0 768 29792 689056 12301536 164059072 1040801344 1459679264 572569728 1274240\r\nceeceecee/cccecce: 1083801600 0 0 0 0 0 0 1984 64960 1373056 22558976 227917632 515214592 312608128 4062272\r\ncccecce/ceeceecee: 1083801600 0 0 0 0 0 0 1984 64960 1373056 22558976 227917632 515214592 312608128 4062272\r\ncccceeee/cccceeee: 3251404800 0 0 0 64 1856 33792 513472 7128960 85727168 654021696 1485339008 964517760 54120896 128\r\nccceceee/cccceeee: 3251404800 0 0 0 0 0 256 12448 339392 7122368 118361728 1003414144 1506607968 615153440 393056\r\ncccceeee/ccceceee: 3251404800 0 0 0 0 0 256 12448 339392 7122368 118361728 1003414144 1506607968 615153440 393056\r\nccceecee/cccceeee: 3251404800 0 0 0 0 0 2560 108864 2683712 44538368 434644224 1417536256 1188371712 163518912 192\r\ncccceeee/ccceecee: 3251404800 0 0 0 0 0 2560 108864 2683712 44538368 434644224 1417536256 1188371712 163518912 192\r\nccceeece/cccceeee: 3251404800 0 0 0 0 0 256 12448 339392 7122368 118361728 1003414144 1506607968 615153440 393056\r\ncccceeee/ccceeece: 3251404800 0 0 0 0 0 256 12448 339392 7122368 118361728 1003414144 1506607968 615153440 393056\r\ncceeccee/cccceeee: 1625702400 0 0 0 0 256 8832 184000 3023264 38823360 298084128 723124608 511734720 50718976 256\r\ncccceeee/cceeccee: 1625702400 0 0 0 0 256 8832 184000 3023264 38823360 298084128 723124608 511734720 50718976 256\r\ncceecece/cccceeee: 3251404800 0 0 0 0 0 512 27200 712544 13686080 197865120 1224497248 1427069696 387491872 54528\r\ncccceeee/cceecece: 3251404800 0 0 0 0 0 512 27200 712544 13686080 197865120 1224497248 1427069696 387491872 54528\r\ncceeecce/cccceeee: 3251404800 0 0 0 0 0 384 12096 284352 5674816 93529856 875636352 1530381312 744379136 1506496\r\ncccceeee/cceeecce: 3251404800 0 0 0 0 0 384 12096 284352 5674816 93529856 875636352 1530381312 744379136 1506496\r\ncececece/cccceeee: 812851200 0 0 0 0 0 384 14336 329696 5705808 71343056 338214144 334751760 62491312 704\r\ncccceeee/cececece: 812851200 0 0 0 0 0 384 14336 329696 5705808 71343056 338214144 334751760 62491312 704\r\ncececeec/cccceeee: 3251404800 0 0 0 0 0 512 27200 712544 13686080 197865120 1224497248 1427069696 387491872 54528\r\ncccceeee/cececeec: 3251404800 0 0 0 0 0 512 27200 712544 13686080 197865120 1224497248 1427069696 387491872 54528\r\nceceecec/cccceeee: 3251404800 0 0 0 64 1536 25728 368448 4723872 53039296 408022912 1207836608 1212225696 364456512 704128\r\ncccceeee/ceceecec: 3251404800 0 0 0 64 1536 25728 368448 4723872 53039296 408022912 1207836608 1212225696 364456512 704128\r\nccceceee/ccceceee: 3251404800 0 0 0 0 0 896 32608 672064 11245568 151416800 1048248352 1473010080 566175872 602560\r\nccceecee/ccceceee: 3251404800 0 0 0 0 0 64 10624 348384 7674112 127665632 1041163424 1497404288 576854240 284032\r\nccceceee/ccceecee: 3251404800 0 0 0 0 0 64 10624 348384 7674112 127665632 1041163424 1497404288 576854240 284032\r\nccceeece/ccceceee: 3251404800 0 0 0 64 1600 26880 379456 4791904 53640224 429300736 1322820160 1191491136 248860960 91680\r\nccceceee/ccceeece: 3251404800 0 0 0 64 1600 26880 379456 4791904 53640224 429300736 1322820160 1191491136 248860960 91680\r\ncceeccee/ccceceee: 1625702400 0 0 0 0 0 128 7232 211584 4516976 73085408 550768736 739417248 257558256 136832\r\nccceceee/cceeccee: 1625702400 0 0 0 0 0 128 7232 211584 4516976 73085408 550768736 739417248 257558256 136832\r\ncceecece/ccceceee: 3251404800 0 0 0 0 0 768 28096 628480 11063232 153656672 1066654464 1471064800 547956608 351680\r\nccceceee/cceecece: 3251404800 0 0 0 0 0 768 28096 628480 11063232 153656672 1066654464 1471064800 547956608 351680\r\ncceeecce/ccceceee: 3251404800 0 0 0 0 0 384 18560 508576 10283520 153066560 1064207840 1471739200 551192480 387680\r\nccceceee/cceeecce: 3251404800 0 0 0 0 0 384 18560 508576 10283520 153066560 1064207840 1471739200 551192480 387680\r\ncececece/ccceceee: 812851200 0 0 0 0 0 640 20128 397840 6212744 72149288 329850768 333869016 70341960 8816\r\nccceceee/cececece: 812851200 0 0 0 0 0 640 20128 397840 6212744 72149288 329850768 333869016 70341960 8816\r\ncececeec/ccceceee: 3251404800 0 0 0 0 1152 28960 488064 6714400 74089312 491329056 1159739872 1126267360 391384000 1362624\r\nccceceee/cececeec: 3251404800 0 0 0 0 1152 28960 488064 6714400 74089312 491329056 1159739872 1126267360 391384000 1362624\r\nceceecec/ccceceee: 3251404800 0 0 0 0 0 832 28448 617536 10756800 146770784 1015659936 1477030656 599257216 1282592\r\nccceceee/ceceecec: 3251404800 0 0 0 0 0 832 28448 617536 10756800 146770784 1015659936 1477030656 599257216 1282592\r\nccceecee/ccceecee: 3251404800 0 0 0 128 3584 63232 926592 11977504 127866528 779917536 1436852896 833743936 60052800 64\r\nccceeece/ccceecee: 3251404800 0 0 0 0 0 64 10624 348384 7674112 127665632 1041163424 1497404288 576854240 284032\r\nccceecee/ccceeece: 3251404800 0 0 0 0 0 64 10624 348384 7674112 127665632 1041163424 1497404288 576854240 284032\r\ncceeccee/ccceecee: 1625702400 0 0 0 0 0 1152 50944 1278016 21466752 211137504 700294208 600433696 91039296 832\r\nccceecee/cceeccee: 1625702400 0 0 0 0 0 1152 50944 1278016 21466752 211137504 700294208 600433696 91039296 832\r\ncceecece/ccceecee: 3251404800 0 0 0 0 0 128 11968 390880 8669120 144557344 1110685600 1480492576 506335712 261472\r\nccceecee/cceecece: 3251404800 0 0 0 0 0 128 11968 390880 8669120 144557344 1110685600 1480492576 506335712 261472\r\ncceeecce/ccceecee: 3251404800 0 0 0 0 352 10784 219072 3485536 44114944 363009120 1101764608 1255821664 479603424 3375296\r\nccceecee/cceeecce: 3251404800 0 0 0 0 352 10784 219072 3485536 44114944 363009120 1101764608 1255821664 479603424 3375296\r\ncececece/ccceecee: 812851200 0 0 0 128 2848 44672 594768 6764104 56411824 192441176 270343184 207082312 79072976 93208\r\nccceecee/cececece: 812851200 0 0 0 128 2848 44672 594768 6764104 56411824 192441176 270343184 207082312 79072976 93208\r\ncececeec/ccceecee: 3251404800 0 0 0 0 0 128 11968 390880 8669120 144557344 1110685600 1480492576 506335712 261472\r\nccceecee/cececeec: 3251404800 0 0 0 0 0 128 11968 390880 8669120 144557344 1110685600 1480492576 506335712 261472\r\nceceecec/ccceecee: 3251404800 0 0 0 0 0 1024 31168 629568 10441728 141278272 1015149760 1483176768 600079744 616768\r\nccceecee/ceceecec: 3251404800 0 0 0 0 0 1024 31168 629568 10441728 141278272 1015149760 1483176768 600079744 616768\r\nccceeece/ccceeece: 3251404800 0 0 0 0 0 896 32608 672064 11245568 151416800 1048248352 1473010080 566175872 602560\r\ncceeccee/ccceeece: 1625702400 0 0 0 0 0 128 7232 211584 4516976 73085408 550768736 739417248 257558256 136832\r\nccceeece/cceeccee: 1625702400 0 0 0 0 0 128 7232 211584 4516976 73085408 550768736 739417248 257558256 136832\r\ncceecece/ccceeece: 3251404800 0 0 0 0 1152 28960 488064 6714400 74089312 491329056 1159739872 1126267360 391384000 1362624\r\nccceeece/cceecece: 3251404800 0 0 0 0 1152 28960 488064 6714400 74089312 491329056 1159739872 1126267360 391384000 1362624\r\ncceeecce/ccceeece: 3251404800 0 0 0 0 0 384 18560 508576 10283520 153066560 1064207840 1471739200 551192480 387680\r\nccceeece/cceeecce: 3251404800 0 0 0 0 0 384 18560 508576 10283520 153066560 1064207840 1471739200 551192480 387680\r\ncececece/ccceeece: 812851200 0 0 0 0 0 640 20128 397840 6212744 72149288 329850768 333869016 70341960 8816\r\nccceeece/cececece: 812851200 0 0 0 0 0 640 20128 397840 6212744 72149288 329850768 333869016 70341960 8816\r\ncececeec/ccceeece: 3251404800 0 0 0 0 0 768 28096 628480 11063232 153656672 1066654464 1471064800 547956608 351680\r\nccceeece/cececeec: 3251404800 0 0 0 0 0 768 28096 628480 11063232 153656672 1066654464 1471064800 547956608 351680\r\nceceecec/ccceeece: 3251404800 0 0 0 0 0 832 28448 617536 10756800 146770784 1015659936 1477030656 599257216 1282592\r\nccceeece/ceceecec: 3251404800 0 0 0 0 0 832 28448 617536 10756800 146770784 1015659936 1477030656 599257216 1282592\r\ncceeccee/cceeccee: 812851200 0 0 16 400 6128 77600 892224 9323408 72924832 235458048 309914592 161565952 22687808 192\r\ncceecece/cceeccee: 1625702400 0 0 0 0 0 0 960 80064 2767104 60680448 558566000 752050384 251517136 40304\r\ncceeccee/cceecece: 1625702400 0 0 0 0 0 0 960 80064 2767104 60680448 558566000 752050384 251517136 40304\r\ncceeecce/cceeccee: 1625702400 0 0 0 0 0 0 2688 102016 2412256 43421536 427908128 768607008 382528128 720640\r\ncceeccee/cceeecce: 1625702400 0 0 0 0 0 0 2688 102016 2412256 43421536 427908128 768607008 382528128 720640\r\ncececece/cceeccee: 406425600 0 0 0 0 0 0 448 33504 949552 18120096 143842176 185056816 58420624 2384\r\ncceeccee/cececece: 406425600 0 0 0 0 0 0 448 33504 949552 18120096 143842176 185056816 58420624 2384\r\ncececeec/cceeccee: 1625702400 0 0 0 0 0 0 960 80064 2767104 60680448 558566000 752050384 251517136 40304\r\ncceeccee/cececeec: 1625702400 0 0 0 0 0 0 960 80064 2767104 60680448 558566000 752050384 251517136 40304\r\nceceecec/cceeccee: 1625702400 0 0 0 64 1792 35648 558144 7103424 68560864 317064416 498386080 486692960 245344320 1954688\r\ncceeccee/ceceecec: 1625702400 0 0 0 64 1792 35648 558144 7103424 68560864 317064416 498386080 486692960 245344320 1954688\r\ncceecece/cceecece: 3251404800 0 0 0 0 0 0 5120 215232 5712224 108580512 985470272 1516513184 634514784 393472\r\ncceeecce/cceecece: 3251404800 0 0 0 0 0 0 2240 123328 3666880 76967904 857571840 1546843840 764461440 1767328\r\ncceecece/cceeecce: 3251404800 0 0 0 0 0 0 2240 123328 3666880 76967904 857571840 1546843840 764461440 1767328\r\ncececece/cceecece: 812851200 0 0 0 0 0 0 832 42752 1263104 26485216 254017248 379776336 151144416 121296\r\ncceecece/cececece: 812851200 0 0 0 0 0 0 832 42752 1263104 26485216 254017248 379776336 151144416 121296\r\ncececeec/cceecece: 3251404800 0 0 64 1536 24960 339200 4072800 42624288 308894304 774391520 877145504 806124000 435564768 2221856\r\ncceecece/cececeec: 3251404800 0 0 64 1536 24960 339200 4072800 42624288 308894304 774391520 877145504 806124000 435564768 2221856\r\nceceecec/cceecece: 3251404800 0 0 0 0 0 0 2688 115744 3169600 66108960 777815520 1555725344 844714592 3752352\r\ncceecece/ceceecec: 3251404800 0 0 0 0 0 0 2688 115744 3169600 66108960 777815520 1555725344 844714592 3752352\r\ncceeecce/cceeecce: 3251404800 0 0 0 128 3456 56576 755584 8992128 91836160 577502464 1283492352 1039074560 249614848 76544\r\ncececece/cceeecce: 812851200 0 0 0 128 2848 44672 590864 6676616 55370000 184885264 239377672 214229168 111084216 589752\r\ncceeecce/cececece: 812851200 0 0 0 128 2848 44672 590864 6676616 55370000 184885264 239377672 214229168 111084216 589752\r\ncececeec/cceeecce: 3251404800 0 0 0 0 0 0 2240 123328 3666880 76967904 857571840 1546843840 764461440 1767328\r\ncceeecce/cececeec: 3251404800 0 0 0 0 0 0 2240 123328 3666880 76967904 857571840 1546843840 764461440 1767328\r\nceceecec/cceeecce: 3251404800 0 0 0 0 0 0 6144 276032 6992192 117638656 926066048 1505936448 692638016 1851264\r\ncceeecce/ceceecec: 3251404800 0 0 0 0 0 0 6144 276032 6992192 117638656 926066048 1505936448 692638016 1851264\r\ncececece/cececece: 203212800 1 32 433 4842 50424 496354 4356750 25756434 46028208 25614194 19053576 49529984 32117008 204560\r\ncececeec/cececece: 812851200 0 0 0 0 0 0 832 42752 1263104 26485216 254017248 379776336 151144416 121296\r\ncececece/cececeec: 812851200 0 0 0 0 0 0 832 42752 1263104 26485216 254017248 379776336 151144416 121296\r\nceceecec/cececece: 812851200 0 0 0 0 0 0 0 10240 490048 13576720 188391696 392390576 217543856 448064\r\ncececece/ceceecec: 812851200 0 0 0 0 0 0 0 10240 490048 13576720 188391696 392390576 217543856 448064\r\ncececeec/cececeec: 3251404800 0 0 0 0 0 0 5120 215232 5712224 108580512 985470272 1516513184 634514784 393472\r\nceceecec/cececeec: 3251404800 0 0 0 0 0 0 2688 115744 3169600 66108960 777815520 1555725344 844714592 3752352\r\ncececeec/ceceecec: 3251404800 0 0 0 0 0 0 2688 115744 3169600 66108960 777815520 1555725344 844714592 3752352\r\nceceecec/ceceecec: 3251404800 0 32 576 7520 87200 937024 9483936 84080704 466269504 752979648 633919808 775750528 515941376 11946944\r\n','216.64.59.154',1135196558,0,0,'3/','a:1:{i:0;i:0;}'),(91,0,35,35,'10 moves max','An interesting result: Using the God\'s Algorithm tables, I can say that all even parity permutations of square/square are at most 10 flips from start (which also means that if you don\'t care about the flip state of the center piece, even parity permutations of square/square are at most 9 from start).','216.64.59.154',1135254232,0,0,'4/','a:1:{i:0;i:0;}'),(92,0,36,23,'\"Group that fixes edges\" is c','\"Group that fixes edges\" is clear. Could you clarify \"Group that fixes cubies\"? I\'m not sure which cubies are being fixed.','68.47.230.99',1135645456,0,0,'1/','a:1:{i:0;i:0;}'),(93,92,36,31,'Re: \"Group that fixes edges\" is c','I\'m pretty sure that by \"Group that fixes cubies,\" Silviu means the group where the locations of all cubies are fixed, but their orientations may change (as long as the conservation of flips and conservation of twists are satisfied). There are 2048*2187 = 4,478,976 total positions in that group, in agreement with Silviu\'s data.
\r\n\r\nMy analysis of the permutations of the cubies showed that the cubies can be placed in the correct positions (but not necessarily in the proper orientation) in 18 quarter turns or less. The cubies can then be oriented using no more than 24 additional quarter turns. Thus, this provides a way of solving the cube with no more than 42 quarter turns. (Of course, Silviu had already found that solving edges first, then solving the corners without any net effect on the edges, is another two-phase method that is superior in terms of the number of quarter turns required.)
\r\n - Bruce Norskog','70.19.249.125',1135707355,0,0,'1.1/','a:1:{i:0;i:0;}'),(94,93,36,34,'Re: 42q','We give a proof below that any cube can be solved in 40q using the above analysis:\r\n\r\nYou can take each position that requires 24q and compute 12 different solutions, each of this 12 solutions ending with one of the 12 generators {U,L,F,B,R,D,U^-1,L^-1,F^-1,B^-1,R^-1,D^-1}. And when you want to solve an arbitrary element g in the cube group you first multiply it by B^-1 from the right and take it to the \"group that fixes cubies\" and then multiply it by an element in that group to take it to the identity. \r\n\r\nSo g*B^-1*A^-1=id ->g=A*B. \r\n\r\nIf A requires 22q or less then then the length of g is 40 or less.\r\n\r\nIf A requires 24q then we write B as X*C where X is one of the twelve generators. And C is an element of length 17 or less.\r\n\r\nWe assumed that A can be written as D*X^-1 and D is of length 23. That is because we assumed we have a solution that ends with any generator. And when combining solutions we get that g=AB=D*X^-1*X*C. We get cancellation which shows that any cube can be done in 40q max.\r\n\r\nThus the only thing we have to show is that the 24q positions are local maxima. For that we need to take each position g in the \"group that fixes cubies\" that requires 24q, multiply it by each generator from the right, and check if the new position requires 23q. The total number of positions are 4 and multiplied by each generator gives 48 positions needed to be solved optimally. One such position requires typically 10-20 hours on Michael Reids solver so it is not unreasonable. \r\n\r\nThe method above is just a special case of the method i used to show that any cube can be solved in 28f. \r\n\r\nIn case someone wants to do this analysis i give the 24q positions:\r\n\r\n1.) F R\' U B2 U R D F U\' B R B2 D B R\' U\' F\' B R U2 D\' (24q*,21f)\r\n2.) F R\' F2 R\' U F U L B2 R B D2 F R\' B\' D B L\' D\' R\' U\' (24q*, 21f)\r\n3.) F R D2 B\' R\' F R\' D2 B\' D\' L F L2 U B\' U F L2 U\' B\' (24q*, 20f)\r\n4.) superflip\r\n\r\nThe superflip is already known to be a local maxima so no investigation is needed for that one.\r\n\r\nI have also computed optimal solutions in the face turn metric for this particular positions and two of them required 20f and one 19f. \r\n\r\n','213.112.65.75',1135790819,0,0,'1.1.1/','a:1:{i:0;i:0;}'),(95,0,36,28,'Optimal Solutions in Half Turn Metric?','How long did it take to compute these tables? Do you also have results in HTM?','217.224.114.251',1137437274,0,0,'2/','a:1:{i:0;i:0;}'),(96,95,36,34,'Time to compute the tables','I estimate 20-25 days for the group that fixes cubies on one computer with a program in GAP (20 times slower than C++). But i used 10 computers so the calculation was finished in 2-3 days. I have not done the face turn metric yet but the time would be aproximately the same. For the group that fixes edges it took me approx 70 days on one computer. But as usual i used more computers.','213.112.65.38',1137456434,0,0,'2.1/','a:1:{i:0;i:0;}'),(97,96,36,28,'FTM results for fixed edges','I really would be interested, if all cubes that fix edges could be solved within 20 moves in FTM , how many and which cubes need 20 moves and which symmetries these cubes have.\r\nI myself have optimized the maneuvers for all symmetric cubes of kind O_h, D_3d, T_h, C_3v, T, D_4h, D_3, D_4, D_2d, C_4v, C_4h (see Cube Explorer for the definitions of these symmetries) and found 42 cubes which need 20 moves ( and no which need more). I used a new optimal solver for this purpose , which optimally solves a random cube in less than two minutes on my PC on average. ','217.224.88.5',1137614763,0,0,'2.1.1/','a:1:{i:0;i:0;}'),(98,97,36,34,'Re:FTM results for fixed edges','This is an incredible result for a completely random position. I have developed several versions of my algorithm and it seems to be finished now. If you want me to I can try to put some computers at work on \"the group that fixes edges\" for the face turn metric and send you the maneuvers. I forgot to thank you personally in the previous message for sharing your Cube Explorer. This is probably the best solver for the face turn metric and it helped me a lot with the 28f proof.','213.112.65.38',1137617520,0,0,'2.1.1.1/','a:1:{i:0;i:0;}'),(99,98,36,28,'Re.FTM results for fixed edges','If you have the possibility to do the computation, this would be great! I hope you can publish the results soon.','217.224.120.128',1137660151,0,0,'2.1.1.1.1/','a:1:{i:0;i:0;}'),(100,99,36,34,'Re:FTM','I will start working on the problem tomorrow. If we are lucky I will have the results next week.\r\n\r\n','213.112.65.38',1137701475,0,0,'2.1.1.1.1.1/','a:1:{i:0;i:0;}'),(101,1,3,39,'That\'s the basic algorithm be','That\'s the basic algorithm behind all optimal solvers, including mine, Reid\'s, and others. The proof is in the pudding (what data structures do you use, do you project the space in any way, etc.)','64.160.186.130',1138147938,0,0,'1.1/','a:1:{i:0;i:0;}'),(102,0,40,39,'So can you share what your fi','So can you share what your final canonicalization code looks like? I\'m not sure I fully understand everything you wrote, and actually writing out the final canonicalization code (without the initialization code) would I think be very helpful. Thanks! -tom','64.160.186.130',1138219264,0,0,'1/','a:1:{i:0;i:0;}'),(103,102,40,23,'I\'ll include some of the code','I\'ll include some of the code below as requested. I don\'t think you will find it very useful without a little more context. It\'s a part of a C++ class library I\'ve been working on.\r\n\r\n// ----------------------------------------------------------------------\r\n\r\n\r\n // Form the representative element y = rep(x) = min{m\'xm}, where\r\n // the minimum is taken over the 48 elements of M, the symmetry\r\n // group of the cube. This is a faster version than the\r\n // basic code in repslow. Invoke as y.repfast(x);\r\n\r\n\r\nvoid corners::repfast(const corners &x )\r\n {\r\n\r\n\r\n unsigned char i, i2, lasti2, xti, t1, j, m, wmin;\r\n\r\n // determine minimum value of w for m\'xm: 0->w\r\n // across all m values. this has been partially\r\n // precalculated, but the completion of the\r\n // calculation depends upon the specific x\r\n // being conjugated\r\n\r\n // (for j=0; j <=7; j++)) unrolled for speed\r\n wmin = w[0][ x.tabs[0] ][0];\r\n if (wmin > w[1][ x.tabs[1] ][0]) wmin = w[1][ x.tabs[1] ][0];\r\n if (wmin > w[2][ x.tabs[2] ][0]) wmin = w[2][ x.tabs[2] ][0];\r\n if (wmin > w[3][ x.tabs[3] ][0]) wmin = w[3][ x.tabs[3] ][0];\r\n if (wmin > w[4][ x.tabs[4] ][0]) wmin = w[4][ x.tabs[4] ][0];\r\n if (wmin > w[5][ x.tabs[5] ][0]) wmin = w[5][ x.tabs[5] ][0];\r\n if (wmin > w[6][ x.tabs[6] ][0]) wmin = w[6][ x.tabs[6] ][0];\r\n if (wmin > w[7][ x.tabs[7] ][0]) wmin = w[7][ x.tabs[7] ][0];\r\n\r\n tabs[0] = wmin; // known to be the case by the way wmin was calculated\r\n tabs[1] = 24; // force scan of all cubies first time through\r\n\r\n\r\n // process only those values for m such that\r\n // m\'xm: 0->w. the values are precalculated in\r\n // the w array.\r\n\r\n for (i = 0; i <= 7; i++) if (w[i][ x.tabs[i] ][0] == wmin )\r\n {\r\n\r\n lasti2 = w[i][ x.tabs[i] ][1]; // calculate outside i2 loop\r\n xti = x.tabs[i]; // calculate outside i2 loop\r\n\r\n for (i2 = 2; i2 <= lasti2; i2++)\r\n {\r\n m = w[i][xti] [i2];\r\n for (j = 1; j <= 7; j++) // loop through 7 bytes of the corner\r\n // (first byte is already set)\r\n {\r\n t1 = x.rep1(m,j);\r\n if (t1 > tabs[j]) // y is better than m\'xm, go to next m\r\n { // by forcing the end of the j loop\r\n j = 8;\r\n }\r\n else if (t1 < tabs[j]) // m\'xm is better than y, so\r\n { // set y = m\'xm (new candidate)\r\n tabs[j] = t1;\r\n for (j++; j <= 7; j++) // loop through rest of j\'s\r\n {\r\n tabs[j] = x.rep1(m,j); // y = m\'xm for rest of new y\r\n }\r\n j=8; // force end of j loop\r\n }\r\n\r\n // if (t1 == tabs[j]), then do nothing except go to next byte\r\n // and going to the next byte is implicit. So the if\r\n // (t1 == tabs[j]) test need not be made.\r\n }\r\n }\r\n }\r\n };\r\n\r\n\r\n\r\n\r\n// ----------------------------------------------------------------------\r\n\r\n // The rep1 routine is used as a part of the process of\r\n // calculating the representative element y = rep(x) = min{m\'xm}, where\r\n // the minimum is taken over the 48 elements of M, the symmetry\r\n // group of the cube. x is the *this argument.\r\n\r\n // The rep1 routine is called by rep to calculate only one byte\r\n // of m\'xm in order to keep the logic of rep itself much cleaner.\r\n\r\n\r\ninline unsigned char corners::rep1(const unsigned char &m, const unsigned char &j) const\r\n {\r\n\r\n unsigned char t1, t2;\r\n\r\n t1 = M_inv[m][j];\r\n\r\n if (t1 <= 7) t2 = tabs[t1];\r\n else if (t1 <= 15)\r\n {\r\n t2 = (unsigned char)(tabs[ t1-8 ] + 8);\r\n if (t2 >= 24) t2 -= (unsigned char)24;\r\n }\r\n else\r\n {t2 = (unsigned char)(tabs[ t1-16 ] + 16);\r\n if (t2 >= 24) t2 -= (unsigned char)24;\r\n };\r\n\r\n// m\'x has been calculated. Now calculate\r\n// (m\'x)m by multiplying by m.\r\n\r\n return M[m][t2];\r\n\r\n };\r\n\r\nFor handling symmetry, I use the idea used in Mike Reid\'s optimal\r\nsolver program\r\nwhere one or two \"coordinates\" describing the cube position are converted\r\nto a \"sym-coordinate\" (the term used in the Cube Explorer documentation),\r\nand a symmetry value (an index specifying which element of M is\r\nused to convert from the representative to the particular position).\r\nI have written most of this before I saw Herbert Kociemba\'s reply,\r\nbut basically I am using the same technique as he describes.\r\nI may express it in different words, and will use as an example my\r\nprogram for analyzing the permutation of the corners and edges\r\n(ignoring orientation).
\r\n\r\nIn my analysis of the permutations of the corners and\r\nedges (ignoring orientation), each position consists of an edge permutation\r\nvalue gep (0..12!-1) and a corner permutation\r\ngcp (0..8!-1).\r\nI used symmetry to convert gcp to a corner\r\nsym-coordinate gcs (0..983) and symmetry code\r\ngsym (0..47).\r\nLookup tables allow for converting between the two coordinate systems.
\r\n\r\nSo let\'s say I know the corner permutation gcp and\r\nedge permutation gep of a cube position g.\r\nI use a lookup table to get which element m of M was used\r\nto generate gcp from its representative.\r\nI use m\', the inverse of m, to generate the corner\r\npermutation of the representative.\r\nSo let r be the cube position of the representative.\r\nThen gcp = m\'rcpm\r\nor rcp = mgcpm\'.\r\nI also use m\' to generate the corresponding\r\nedge permutation coordinate (rep = mgepm\').\r\nHowever, this edge coordinate will not always be the correct value\r\nfor the \"true\" representative, as m was determined from the\r\ncorner permutation information only.\r\nIn some cases, there are multiple edge permutations paired with the same corner\r\npermutation in a set of symmetrically equivalent elements.
\r\n\r\nNote: I may be a little lax in my notation, using numerical coordinates as if they\r\nare a group element. But in my example, the edge permutation and corner\r\npermutation are independent coordinates, in the sense that one can make the\r\ncalculations (conjugating by a symmetry element) for either coordinate without\r\nknowing the other coordinate\'s value.\r\n\r\nMike Reid\'s program calculates a \"stabilizer\" value for each possible value\r\nof the sym-coordinate.\r\nEssentially, this is a bitvector specifying which elements in M have the\r\nproperty m\'gcpm = gcp.\r\n(Note, Mike Reid\'s optimal solver program used a subgroup of M with\r\n16 elements, not the full M of 48 elements.\r\nThis is due to the properties of the cube subgroup he was working with.)\r\nIn my case, I was using the full symmetry group M, so in my case\r\nthe stabilizer values contain 48 bits.\r\nTo find the representative for a position, I only need to consider the elements\r\nof M for which the corresponding bit in the stabilizer value is a 1.\r\nNote that a large proportion of the corner permutation representatives have a\r\nstabilizer value of 1 (47 bits that are 0 and only the LSB is 1), meaning that there\r\nis \"no symmetry\" in that particular corner permutation.\r\nWhen this is the case, there are no other possibilities for m to consider\r\nregardless of the value of the edge permutation coordinate.
\r\n\r\nMy program uses a table of 984 files, one for each corner sym-coordinate.\r\nA 4-bit value is stored for each edge permutation with parity matching that\r\nof the corner permutation associated with the particular file.\r\nSo the table has a total size of 984*(12!/2) nibbles.\r\nThis is larger than the number of true representatives, so there\r\nare some elements of the table that are not true representatives.\r\n(One can consider that all the table elements are \"representatives\" for some set\r\nof elements in the whole group, but in some cases, it takes more than one of\r\nthese sets to make up a complete set of elements that are equivalent when\r\ntaking symmetry into account.\r\nSaying this another way, a set of equivalent elements may be represented by\r\nmore than one element of the table, but only one of those table elements\r\ncorrespond to the true representative,\r\nthat one which comes first lexicographically.)\r\n\r\nI have chosen to set all table elements having the same representative to the\r\nsame distance value, once I determine the value for one of them.\r\nThen, when looking up a value, I don\'t need to worry about whether or not\r\nI have found the \"correct\" representative.\r\nOn the other hand, I have the task of finding all table entries equivalent to a given one.\r\nThis I do by iterating over the elements of M where the\r\ncorresponding stabilizer bit is a 1,\r\nand calculating the corresponding edge permutation for each.\r\nWhile this code to search for the other equivalent table elements is somewhat expensive\r\n(and could be optimized further I am sure), I actually avoid the problem of ever\r\nhaving to find the true representative for a position.
\r\n\r\nIf I later go through the table, for example, to count the number of true\r\nrepresentatives in the table for a specified distance, I only have to check for\r\neach element if it is the representative.\r\nI don\'t actually have to find the representative for each element.\r\nThat is, I only have to search (using the stabilizer bitvector as a search filter)\r\nuntil I find an equivalent element that is lexicographically smaller. If the element\r\nhas the right distance, and it is the true representative, I count it.\r\nOtherwise I don\'t count it. Still, my code is very time-consuming as it stands\r\nright now (when iterating over the whole table of over 200 billion elements).\r\nI was more concerned with making sure it worked correctly than\r\nin getting the highest performance possible.
\r\n\r\n - Bruce Norskog','70.22.142.200',1138302806,0,0,'3/','a:1:{i:0;i:0;}'),(111,0,36,39,'I still am not sure of the nu','I still am not sure of the numbers. For the group that fixes edges, I get the same values for 0q..14q, but at 16q we diverge sharply. Your values are (840513, 17620, 9091) and I get (1075761, 22536, 11588).\r\n\r\nI\'ve put the 11588 unique length 16q sequences in the file http://tomas.rokicki.com/16q.txt. I\'ve verified these are unique and I\'ve verified they are canonical; the sequences given are all of length 16.\r\n\r\nSo either I\'ve got a major bug somewhere, or I\'m misunderstanding something. The fact that we agree on 0..14 would seem to contradict the latter.\r\n\r\nAnyone see what I\'m doing wrong?','64.160.186.130',1138308869,0,0,'4/','a:1:{i:0;i:0;}'),(112,111,36,34,'Re:','I dont have a clue why. But let us do following test. I got following for the face turn metric:\r\n\r\n19f 216 (7 unique w.r.t M + inv)\r\n18f 827386\r\n17f 20029566\r\n16f 16944222\r\n15f 4905894\r\n14f 1084624\r\n13f 217374\r\n12f 72008\r\n11f 5220\r\n10f 2521\r\n9f 360\r\n8f 528\r\n7f 0\r\n6f 0\r\n5f 0\r\n4f 0\r\n3f 0\r\n2f 0\r\n1f 0\r\n0f 1\r\n\r\n\r\nThe positions needing 19f in generator form:\r\nF U D2 R2 L2 F2 B\' U\' L2 B U B D L2 F2 D2 L2 F2 U2 \r\nR2 B\' R2 L2 U2 B2 D\' B2 D2 F\' R2 L2 D\' R2 U2 B2 U B2 D\' \r\nR U R\' B2 L U\' R2 L U\' F2 R L2 B2 U\' R2 D2 R2 D B2 \r\nU2 B R2 B2 U R2 U B\' D F2 L2 B D\' R2 F2 R2 L2 D\' F2 \r\nR\' U D\' L B2 R\' L U\' B2 D B2 R\' D R2 F2 D F2 L2 U \r\nU B2 D2 R2 D\' R2 B2 D\' F\' U L2 D B\' R2 U2 B U\' L2 F\' \r\nR2 D L2 D\' L2 F D F\' R2 F U\' B\' L2 B L2 B\' U L2 F\' \r\n\r\nCan you see if you get the same for this?\r\n\r\n\r\n\r\n','213.112.65.81',1138310344,0,0,'4.1/','a:1:{i:0;i:0;}'),(113,112,36,39,'We agree up to 17f; I haven\'t','We agree up to 17f; I haven\'t run 18f or 19f yet myself.\r\n\r\nHow did you run that so fast, BTW?','64.160.186.130',1138311511,0,0,'4.1.1/','a:1:{i:0;i:0;}'),(114,111,36,34,'Re:Error in calculations','Now when I am thinking closer, I realise that I might have some error since you clearly found more positions then I did. I will look at the problem as soon as possible. \r\nHave you verified the other depths?\r\nHave you verified the group that fixes cubies?','213.112.65.81',1138311741,0,0,'4.2/','a:1:{i:0;i:0;}'),(115,114,36,39,'I\'m working on the other dept','I\'m working on the other depths. It may take me several (days/weeks/months). I haven\'t verified the group that fixes cubies (I\'m not using GAP; perhaps I should learn?)','64.160.186.130',1138311839,0,0,'4.2.1/','a:1:{i:0;i:0;}'),(116,113,36,34,'Re:','Nice to see that we agree on this one. \r\n\r\nI have an own algorithm that I will publish everything about as soon as possible and I have also used several powerful computers on this task.\r\n','213.112.65.81',1138312946,0,0,'4.1.1.1/','a:1:{i:0;i:0;}'),(117,115,36,34,'RE:','The face turn metric computation took me 4 days on 10 computers.','213.112.65.81',1138313183,0,0,'4.2.1.1/','a:1:{i:0;i:0;}'),(118,97,36,39,'Wow, 2minutes is fast. How l','Wow, 2minutes is fast. How long does it take to optimally solve a 19f* position? I can send you a bunch to try if you want. Is the new optimal solver available anywhere?','64.160.186.130',1138315006,0,0,'2.1.1.2/','a:1:{i:0;i:0;}'),(119,118,36,34,'Re:','Hi I have redone depth 16 and got exactly the same number as you did. \r\n\r\nThe solver will be available very soon. A friend of mine is almost finished writing a C++ version. I estimate 1 month maximum until it will be available.','213.112.65.81',1138315966,0,0,'2.1.1.2.1/','a:1:{i:0;i:0;}'),(120,112,36,39,'I confirm all those numbers:\r','I confirm all those numbers:\r\n\r\n| dep | arrangements | M | M+inv |
| 0 | 1 | 1 | 1 |
| 8 | 528 | 11 | 6 |
| 9 | 360 | 8 | 5 |
| 10 | 2521 | 63 | 43 |
| 11 | 5220 | 117 | 68 |
| 12 | 72008 | 1541 | 821 |
| 13 | 217374 | 4584 | 2378 |
| 14 | 1084624 | 22743 | 11690 |
| 15 | 4905894 | 102419 | 51896 |
| 16 | 16944222 | 353629 | 178786 |
| 17 | 20029566 | 418360 | 212304 |
| 18 | 827386 | 17502 | 9419 |
| 19 | 216 | 7 | 7 |
| 44089920 | 920985 | 467424 |
| 16 | 1 |
| 17 | 23 |
| 18 | 283 |
| 19 | 2336 |
| 20 | 11300 |
| 21 | 14543 |
| 22 | 5465 |
| 23 | 19 |
\r\nSTM FTM-->\r\n v 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 Total\r\n 0: 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1\r\n 1: 0 6 0 0 0 0 0 0 0 0 0 0 0 0 0 6\r\n 2: 0 2 22 0 0 0 0 0 0 0 0 0 0 0 0 24\r\n 3: 0 0 12 81 0 0 0 0 0 0 0 0 0 0 0 93\r\n 4: 0 0 1 64 276 0 0 0 0 0 0 0 0 0 0 341\r\n 5: 0 0 0 12 298 820 0 0 0 0 0 0 0 0 0 1130\r\n 6: 0 0 0 0 96 1140 2100 0 0 0 0 0 0 0 0 3336\r\n 7: 0 0 0 0 8 517 3624 4600 0 0 0 0 0 0 0 8749\r\n 8: 0 0 0 0 0 50 1652 8964 8156 0 0 0 0 0 0 18822\r\n 9: 0 0 0 0 0 0 66 3456 17056 11984 0 0 0 0 0 32562\r\n 10: 0 0 0 0 0 0 0 68 6296 23956 14512 0 0 0 0 44832\r\n 11: 0 0 0 0 0 0 0 0 60 8456 25528 15232 0 0 0 49276\r\n 12: 0 0 0 0 0 0 0 0 0 308 6480 27648 9792 0 0 44228\r\n 13: 0 0 0 0 0 0 0 0 0 0 696 6208 16824 4624 0 28352\r\n 14: 0 0 0 0 0 0 0 0 0 0 0 704 2096 6000 576 9376\r\n 15: 0 0 0 0 0 0 0 0 0 0 0 0 312 480 0 792\r\nTotal: 1 8 35 157 678 2527 7442 17088 31568 44704 47216 49792 29024 11104 576 241920\r\n\r\n\r\nJaap\'s Puzzle Page:\r\nhttp://www.geocities.com/jaapsch/puzzles/','134.146.0.41',1138860662,0,0,'1.1.2.1/','a:1:{i:0;i:0;}'),(146,145,39,2,'Great. My own program was ju','Great. My own program was just a quick application to try out different methods of indexing permutations, and wasn\'t checked carefully. Hadn\'t considered the other metric, either. ','130.88.128.98',1138876695,0,0,'1.1.2.1.1/','a:1:{i:0;i:0;}'),(147,139,42,31,'symmetry and deep positions','
In doing various analyses, particularly the huge permutation-of-the-cubies analysis in QTM, I have noticed that the deepest positions tend to have symmetry, even though symmetric positions represent a rather small amount of the total positions. From my permutations analysis, I noticed that all depth 17q positions have symmetry in the corner configuration. Of these 11 (unique wrt M+inv) positions, all but one have symmetry in the edge configuration. That position is the only one that does not have symmetry when both edges and corners are considered. Below I list these 11 positions and the degree of symmetry (how many elements in M do not change the position under conjugation) for the corner configuration, edge configuration, and the overall position. I also show the order of each position.
\r\n\r\n\r\nDepth 17q positions in corner and edge permutations analysis\r\n\r\n Position Symmetries Order\r\n CP EP C E All C E All\r\n ----- --------- -- - --- - - ---\r\n 54 130377481 12 3 3 2 4 4\r\n 127 163710727 4 1 1 2 6 6\r\n 415 3653859 4 4 4 2 2 2\r\n 4761 123758783 12 8 4 2 2 2\r\n 5209 127387463 4 4 2 4 4 4\r\n 9800 127389022 4 2 2 4 4 4\r\n 9800 127390445 4 2 2 4 4 4\r\n 12322 299547493 4 8 4 4 4 4\r\n 14128 409720015 4 4 4 8 8 8\r\n 14128 449636809 4 4 4 8 8 8\r\n 14854 248577983 4 2 2 4 8 8\r\n\r\n - Bruce Norskog','151.204.244.69',1138928874,0,0,'1.1/','a:1:{i:0;i:0;}'),(148,147,42,39,'Here\'s the distribution of sy','Here\'s the distribution of symmetry for the 74 length-20 positions for the earlier analysis I posted (four sets of 44M solutions):\r\n
\r\n count symmetry\r\n 9 1\r\n 22 2\r\n 6 3\r\n 19 4\r\n 5 6\r\n 10 8\r\n 2 24\r\n 1 48\r\n\r\n\r\nHere a symmetry of 1 means *no* symmetry, and a symmetry of 48 means full M-symmetry.\r\n\r\nCertainly symmetrical positions are overrepresented, but there are a surprisingly large number of asymmetrical positions, too.\r\n','63.197.151.31',1138932581,0,0,'1.1.1/','a:1:{i:0;i:0;}'),(149,148,42,28,'20 move positions with symmetries','Over the last two weeks time I made a list of *all* possible cube positions which have more than 4 symmetries and ran my optimal solver over them.\r\nLess than 200 have length 20 and there are no 21 maneuvers. I can give detailed results and also post the maneuvers, if desired.\r\nSo it is proven that a cube position with length 21 must have 4 or less symmetries.\r\n\r\n ','217.224.90.231',1138944589,0,0,'1.1.1.1/','a:1:{i:0;i:0;}'),(150,149,42,2,'I\'d be interested to see the','I\'d be interested to see the details, if you have time.\r\n\r\n> positions which have more than 4 symmetries\r\n\r\nDo the lower-symmetry 20f cases tend to have antisymmetry? [Suggested by one (!) example,\r\nD\' F2 L2 B2 R F\' L2 D R2 D2 B U F2 L2 R2 D\' L2 F L\' U\' (20f).]\r\n\r\nI wondered if you had considered looking at the antisymmetric cases with 3 and 4 symmetries. ','130.88.128.98',1138965513,0,0,'1.1.1.1.1/','a:1:{i:0;i:0;}'),(151,150,42,23,'I\'m not sure I understand the','I\'m not sure I understand the question. I believe that the way antisymmetry has been used on this list is to refer to the fact that for a position x, the length of the inverse x-1 is the same as the length of x. This approach allows a search space to be reduced by a factor of approximately 96, rather than by a factor of approximately 48 if only symmetry is taken into account. Do you mean that if a position \"has antisymmetry\" that it is not equal to its inverse. Obviously, if a position is equal to its inverse then you can\'t get a 96 times reduction for that particular position.\r\n\r\nIf we take (as per Cube-Lovers) Symm(x) to mean the set (and group) of all m in M such that m-1xm=x, then it is the case that Symm(x-1)=Symm(x). So if Herbert has already checked all positions that have more than four symmetries, then he has automatically also checked their inverses. I assume that by \"more than 4 symmetries\", Herbert means |Symm(x)|>4.','198.146.200.214',1138988352,0,0,'1.1.1.1.1.1/','a:1:{i:0;i:0;}'),(152,151,42,2,'> Do you mean that if a posit','> Do you mean that if a position \"has antisymmetry\" that it is not\r\n> equal to its inverse. \r\n\r\nIf m\'xm = x\', where m is an ordinary symmetry element, then we say that x has the antisymmetry Tm. This is the same terminology that Herbert and I have used earlier on this list.\r\n\r\nThe combined set of symmetries and antisymmetries of x also form a group, which you might call AntiSymm(x).\r\n\r\n> by \"more than 4 symmetries\", Herbert means |Symm(x)|>4.\r\n\r\nThat would be my understanding, too. \r\n\r\nI simply wondered whether he had thought about extending his calculation to include all of the cases with |AntiSymm(x)| > 4. So far, I think, his results will have included all those with |AntiSymm(x)| > 8.','130.88.128.98',1138992212,0,0,'1.1.1.1.1.1.1/','a:1:{i:0;i:0;}'),(153,151,42,28,'Antisymmetry','We have h^-1xh=x for h in the symmetry group H of x.\r\nIn addition there is a group G, also a subgroup of M. H is a subgroup of index 2 in G and for all g in G which are not in H we have\r\ng^-1xg=x^-1.
When I first read Mark\'s suggestion to extend Thistlethwaite\'s algorithm to the 4x4x4, I thought he was suggesting \r\ngeneralizing each of the nested subgroups of Thistlethwaite\'s algorithm to similar \"groups\" for the 4x4x4, with \r\ncorresponding slice moves included in each of the sets of generators.\r\n(Of course, the positions of a plain 4x4x4 cube do not form a group, but the 4x4x4 supercube is a group, and the plain \r\n4x4x4 can be thought of as a set of positions acted upon by this group.) Calculating God\'s algorithm for the squares \r\ngroup would be a subproblem of this.\r\nAnyway, I soon realized a practical extension of the Thistlethwaite algorithm for the 4x4x4 would need to use other \r\ngroups than those four, since two of them actually would be the entire 4x4x4 supercube group, effectively reducing it to \r\na three-stage algorithm.\r\nI realized it might be even be necessary to use more than four stages, and it might not even include the 4x4x4 squares \r\n\"group\" as one of the sets.
\r\nI decided to use GAP to look at the 4x4x4 supercube, since the supercube positions form a group.\r\nNormally, the 4x4x4 supercube is said to have approximately 7.072*(10^53) positions since the orientation of the puzzle \r\ndoes not matter.\r\nHowever, when discussing groups generated with various sets of generators (where these generators are basic cube moves), \r\nthe orientation does matter.\r\nThe group where orientation does matter has 24 times more positions, or 1.697*(10^55).
\r\nThere are many possible subgroups that could be used in a Thistlethwaite-like algorithm for the 4x4x4 supercube.\r\nI decided to focus on sets of nested groups that would include the squares group.\r\nFor the squares group, the generators U^2, u^2, D^2, F^2, f^2, B^2, R^2, r^2, and L^2 are sufficient.\r\nI considered that no smaller groups needed to be considered (other than the trivial group of 1 element).
\r\nI found groups of twelve different sizes that were subgroups of the supercube, and of which the squares group was a \r\nsubgroup.\r\nI have decided (for this discussion) to call representative groups of these J1 through J12, as given in the table below.\r\nThe Squares group and the whole supercube group (which I\'ll denote as Gs) are also included in the table.\r\nI also attempted to figure out what the number of positions would be for the plain 4x4x4 with four indistinguishable \r\ncenters of each color.\r\nBut, I could be off a factor of 2 or 4 or so on these figures, so I put question marks by those numbers.
\r\n\r\n\"Name\" Generators Approx. Size Plain 4x4x4\r\n\r\nSquares <U2,u2,D2,F2,f2,B2,R2,r2,L2> 9.393*(10^12) 1.5*(10^11) ?\r\nJ1 <U2,u,D2,F2,f2,B2,R2,r2,L2> 6.959*(10^20) 2.7*(10^18) ?\r\nJ2 <U,u2,D2,F2,f2,B2,R2,r2,L2> 2.923*(10^23) 3.2*(10^19) ?\r\nJ3 <U2,u,D2,F2,f,B2,R2,r2,L2> 8.594*(10^29) 8.4*(10^26) ?\r\nJ4 <U,u,D2,F2,f2,B2,R2,r2,L2> 1.083*(10^31) 5.9*(10^26) ?\r\nJ5 <U,u2,D2,F2,f,B2,R2,r2,L2> 8.133*(10^34) 6.1*(10^28) ?\r\nJ6 <U,u2,D2,F,f2,B2,R2,r2,L2> 7.894*(10^35) 5.9*(10^29) ?\r\nJ7 <U2,u,D2,F2,f,B2,R2,r,L2> 1.952*(10^39) 2.0*(10^31) ?\r\nJ8 <U,u,D2,F2,f,B2,R2,r2,L2> 1.055*(10^46) 1.1*(10^38) ?\r\nJ9 <U,u2,D2,F2,f,B2,R2,r,L2> 2.512*(10^43) 2.6*(10^35) ?\r\nJ10 <U,u,D2,F,f2,B2,R2,r2,L2> 2.308*(10^49) 2.4*(10^41) ?\r\nJ11 <U,u2,D2,F,f2,B2,R2,r,L2> 5.495*(10^46) 4.1*(10^40) ?\r\nJ12 <U,u2,D2,F,f2,B2,R,r2,L2> 8.966*(10^44) 9.4*(10^36) ?\r\nGs <U,u,D2,F,f,B2,R,r,L2> 1.697*(10^55) 1.8*(10^47) (supercube)\r\n\r\n\r\n
In the sequences of nested groups below I also use these groups that are isomorphic to J1, J3 and J5, \r\nrespectively.
\r\n
\r\n J1a: <U2,u2,D2,F2,f,B2,R2,r2,L2>\r\n J3a: <U2,u2,D2,F2,f,B2,R2,r,L2>\r\n J5a: <U,u2,D2,F2,f2,B2,R2,r,L2>\r\n\r\n\r\n
I looked for what possible sequence of nested groups might provide the most practical set of subproblems to solve.\r\nI have assumed that the number of positions in the subproblems would be the number of elements of the larger group \r\ndivided by the number of elements in the smaller group.\r\n(Is this necessarily true for these groups?)\r\nI haven\'t worked out the actual number of positions that would be needed to be stored when computing God\'s algorithm for \r\nthat stage. That number will generally be smaller than the factor listed since symmetry and antisymmetry can reduce the \r\nvalue by as much as a factor of 96 (approximately).\r\nMany of these subgroups will not be able to take advantage of all 48 symmetries of M, so a smaller reduction would apply \r\nin those cases.
\r\n\r\nGroup Size Supercube Factor Plain 4x4x4 Factor\r\n----- ---- ---------------- ------------------\r\n\r\n----- Case 1 --------------------------------------------------\r\nGs 1.697*(10^55)\r\n 1,608,475,077 1.6*(10^9) ?\r\nJ8 1.055*(10^46)\r\n 5,405,400 5.4*(10^6) ?\r\nJ7 1.952*(10^39)\r\n 2,271,491,040 2.4*(10^4) ?\r\nJ3 8.594*(10^29)\r\n 1,234,926,000 3.1*(10^8) ?\r\nJ1 6.959*(10^20)\r\n 74,088,000 1.9*(10^7) ?\r\nSquares 9.393*(10^12)\r\n 9,393,093,476,352 1.5*(10^11) ?\r\nI 1\r\n\r\nNote: In the above, J8 -> J3 could possibly be done in one\r\nstep for the plain 4x4x4.\r\n\r\n----- Case 2 --------------------------------------------------\r\nGs 1.697*(10^55)\r\n 675,559,532,340 6.8*(10^11) ?\r\nJ9 2.512*(10^43)\r\n 308,897,820 4.3*(10^6) ?\r\nJ5 8.133*(10^34)\r\n 278,269,992,000 1.9*(10^9) ?\r\nJ2 2.923*(10^23)\r\n 31,116,960,000 2.2*(10^8) ?\r\nSquares 9.393*(10^12)\r\n 9,393,093,476,352 1.5*(10^11) ?\r\nI 1\r\n\r\n----- Case 3 --------------------------------------------------\r\nGs 1.697*(10^55)\r\n 1,608,475,077 1.6*(10^9) ?\r\nJ8 1.055*(10^46)\r\n 129,737,084,400 1.8*(10^9) ?\r\nJ5 8.133*(10^34)\r\n 278,269,992,000 1.9*(10^9) ?\r\nJ2 2.923*(10^23)\r\n 31,116,960,000 2.2*(10^8) ?\r\nSquares 9.393*(10^12)\r\n 9,393,093,476,352 1.5*(10^11) ?\r\nI 1\r\n\r\n----- Case 4 --------------------------------------------------\r\nGs 1.697*(10^55)\r\n 308,897,820 4.3*(10^6) ?\r\nJ11 5.495*(10^46)\r\n 675,559,532,340 6.8*(10^11) ?\r\nJ5a 8.133*(10^34)\r\n 278,269,992,000 1.9*(10^9) ?\r\nJ2 2.923*(10^23)\r\n 31,116,960,000 2.2*(10^8) ?\r\nSquares 9.393*(10^12)\r\n 9,393,093,476,352 1.5*(10^11) ?\r\nI 1\r\n\r\n----- Case 5 --------------------------------------------------\r\nGs 1.697*(10^55)\r\n 308,897,820 4.3*(10^6) ?\r\nJ11 5.495*(10^46)\r\n 69,604,975,440 7.0*(10^10) ?\r\nJ6 7.894*(10^35)\r\n 2,700,783,162,000 1.9*(10^10) ?\r\nJ2 2.923*(10^23)\r\n 31,116,960,000 2.2*(10^8) ?\r\nSquares 9.393*(10^12)\r\n 9,393,093,476,352 1.5*(10^11) ?\r\nI 1\r\n\r\n----- Case 6 --------------------------------------------------\r\nGs 1.697*(10^55)\r\n 735,471 7.4*(10^5) ?\r\nJ10 2.308*(10^49)\r\n 25,740 2.6*(10^4) ?\r\nJ12 8.966*(10^44)\r\n 1,135,754,520 1.6*(10^7) ?\r\nJ6 7.894*(10^35)\r\n 2,700,783,162,000 1.9*(10^10) ?\r\nJ2 2.923*(10^23)\r\n 31,116,960,000 2.2*(10^8) ?\r\nSquares 9.393*(10^12)\r\n 9,393,093,476,352 1.5*(10^11) ?\r\nI 1\r\n\r\nNote: In the above, Gs -> J12 could be done in one step with\r\na factor of 18,931,023,540.\r\n\r\n----- Case 7 --------------------------------------------------\r\nGs 1.697*(10^55)\r\n 1,608,475,077 1.6*(10^9) ?\r\nJ8 1.055*(10^46)\r\n 129,737,084,400 1.8*(10^9) ?\r\nJ5 8.133*(10^34)\r\n 116,873,396,640,000 2.3*(10^10) ?\r\nJ1a 6.959*(10^20)\r\n 74,088,000 1.9*(10^7) ?\r\nSquares 9.393*(10^12)\r\n 9,393,093,476,352 1.5*(10^11) ?\r\nI 1\r\n\r\n----- Case 8 --------------------------------------------------\r\nGs 1.697*(10^55)\r\n 675,559,532,340 6.8*(10^11) ?\r\nJ9 2.512*(10^43)\r\n 29,234,089,684,800 3.1*(10^8) ?\r\nJ3a 8.594*(10^29)\r\n 1,234,926,000 3.1*(10^8) ?\r\nJ1a 6.959*(10^20)\r\n 74,088,000 1.9*(10^7) ?\r\nSquares 9.393*(10^12)\r\n 9,393,093,476,352 1.5*(10^11) ?\r\nI 1\r\n\r\n\r\n
In summary, the above cases above have 5 or 6 stages.\r\nA 4-stage solution is not practical for the supercube, but it looks to me that a 5-stage solution is clearly achievable.\r\nA six-stage supercube solution can be done where only the last stage (the one solving within the Squares group) requires \r\nmore than 2.9*(10^9) positions (Case 1).\r\nIt doesn\'t look to me that a 4-stage solution for the plain 4x4x4 will be practical for any of these cases involving the \r\nsquares group.\r\nThere may be a better cases if you consider other possibilities than the Squares group for the last stage.\r\nThe fourth root of 1.78*(10^47) is approximately 650*(10^9), so it would seem to me at least one stage of a four-stage \r\napproach would probably need to done with the use of disk storage.
\r\nI think I may be willing to work on this problem starting a few weeks from now, after I finish my current project.\r\nI don\'t know if Mark or anyone else has had any thoughts about what nested subgroups to use. It looks to me that Case 3 above would probably be the easiest to do, for either the normal cube or the supercube. Case 1 would seem to be a logical choice for an easier 6-stage solution.
\r\n - Bruce Norskog','70.22.181.85',1139351069,0,0,'1.1/','a:1:{i:0;i:0;}'),(167,164,35,4,'> perhaps minor variations on','> perhaps minor variations on other 13-flip positions would be good candidates for \"deep\" positions in the turn metric.\r\n\r\nThat is a good point. The square-square shape is one of the most symmetric shapes, and therefore also in a sense one of the hardest to get to. Also, other symmetric shapes tend to have easy parity fixes.\r\n\r\nJust as symmetric patterns on the cube are good candidates for being far from start, so are these 13-flip square-square patterns on the square-1.\r\n\r\nJaap\'s Puzzle Page:\r\nhttp://www.geocities.com/jaapsch/puzzles/','134.146.0.41',1139397708,0,0,'3.1.1/','a:1:{i:0;i:0;}'),(168,165,43,28,'Symmetry reductions','I would be interested how you get a reduction of about 45.5 with a position which has 16 symmetries.\r\n\r\nIn the moment I myself do not think so much about symmetry reductions when computing the maneuver for a special position but for symmetry reductions when computing the cubes belonging to one of the 33 symmetry classes and I only want to count and display these cubes up to M-symmetry. My actual method is quite dumb and only works well if there are a few thousend cases. I just generate the next cube in the desired symmetry class and compare it to the already generated cubes if it is equal to any of them wrt M-symmetry and throw it away in this case.\r\n\r\nThe idea for a better method is to generate only the corners with the desired symmetry first and then compare this corner configuration with the already generated corner configurations and throw it away if it already exists up to M-symmetry. If not, the edges are computed.\r\nBut this approach does not work. You lose some configurations. It took me some time to understand why.\r\nThe correct procedure is to throw a corner configuration away only if it is eqivalent to an already computed corner configuration with respect to a subgroup X of M. X is the largest subgroup of M, in which the the symmetry group H which defines the desired symmetry is normal, that is for all x in X we must have\r\nx^-1Hx=H .\r\nThe index of H in X is an approximation for the reduction factor if you only count cases up to M-symmetry.\r\nIf you take for example H:= UD-symmetry (called D_4h in Cube Explorer) as the desired symmetry, X is the same as H and the index of H in X is 1. So there is no symmetry reduction possible at all. There are 128 cases - if you check the \"allow isomorphics\" box or not. ','217.224.121.153',1139494321,0,0,'1.1.1.1/','a:1:{i:0;i:0;}'),(169,105,40,39,'Well I experimented with this','Well I experimented with this technique (the very last one because I\'m pretty much using the others)---and only got a slight speedup (on the order of 10%).\r\n\r\nA different technique gave me a much greater speedup (nearly 3X for the canonicalization step). Let\'s assume I\'m doing canonicalization of edge positions, although this technique also works for edge cubies (with orientation), corner positions, corner cubies, and of course the full cube. What I do is separate the 48 symmetry classes into 6 sets, one for each face. I simply have a table of size 12*12*12*12 that gives me, for a given set of four edges on a face, the best of the eight orientations that preserve that face, and its result as an integer (base 12). Let us assume the first four cubies in our representation pertain to face 0. Essentially, my code then simply does:\r\n\r\n\r\nint bestseen = 999999999 ; some impossibly high value\r\nint mapping_to_use = -1 ; none seen yet\r\nfor (face f in FACES) {\r\n // calculate *a* mapping of this face, to the face sharing\r\n // the first four cubies of our cube representation. We only\r\n // need to calculate four cubies, and we can immediately\r\n // sum them into a table index\r\n mapping m = firstmapping(f, 0) ; // find a mapping that takes f to 0\r\n int ind = calcnewcubie(m, 3) + 12 *\r\n (calcnewcubie(m, 2) + 12 *\r\n (calcnewcubie(m, 1) + 12 *\r\n calcnewcubie(m, 0))) ;\r\n if (bestvalueofeight[ind] < bestseen) {\r\n // new better mapping!\r\n bestseen = bestvalueofeight[ind] ;\r\n mapping_to_use = m + secondarymapping[ind] ;\r\n } else if (bestvalueofeight[ind] == bestseen) {\r\n // saw another way to get this value; use slow method\r\n mapping_to_use = -1 ;\r\n }\r\n}\r\nif (mapping_to_use < 0) {\r\n use_slow_method() ;\r\n} else {\r\n remap(mapping_to_use) ;\r\n}\r\n\r\n\r\nThis way, we get and compare the results of four cubies at a time, which almost always gives us a unique minimum (with a unique mapping that gets us to that minimum). And the code is very simple and fast. Heck, even the multiplications by 12 listed above are actually done by the table lookups that do the orientations themselves.\r\n\r\nOf course this is still slower than using a separate orientation from permutation \"symmcoordinate\", but I haven\'t figured out how to get that to work outside of a UD symmetry world (for instance, for full M-symmetry). Maybe someone has some ideas on this?','63.197.151.31',1139612450,0,0,'1.1.1.1.2/','a:1:{i:0;i:0;}'),(170,169,40,28,'Sym-coordinates for orientations','Sym-coordinates for the orientations of the edges with full M-symmetry are no problem, because you can define a reference frame for the orientations which has M-symmetry. The simplest way to describe this is that every quarter turn changes the orientation of an involved edge.\r\n\r\nFor the corners there is no sym-coordinate with full M-symmetry for the orientations alone. The best you can do to use a coordinate which combines the orientation of the corners with the positions of four corners, which build tetraeder (e.g. urf,urb, dlf and drb, disregarding the order of these corners (70 possibilities), so your sym-coordinate would have about 2187*70/48 different states.','217.224.101.107',1139738983,0,0,'1.1.1.1.2.1/','a:1:{i:0;i:0;}'),(171,0,41,39,'Here\'s the results for the co','Here\'s the results for the coset that has the edges in Reid\'s position (quarter turn metric this time):\r\n\r\n\r\n d pos M M+inv\r\n14 864 55 28\r\n16 48104 3016 1524\r\n18 2003896 125521 63317\r\n20 32050973 2006185 1010090\r\n22 9986060 626478 318134\r\n24 22 4 4\r\n26 1 1 1\r\n 44089920 2761260 1393098\r\n','64.160.186.130',1139862127,0,0,'2/','a:1:{i:0;i:0;}'),(172,168,43,39,'I\'ve done an analysis of your','I\'ve done an analysis of your symmetric positions listed above, and very few of them show the type of symmetric exploration reduction I saw for Reid\'s position (the 45.5 reduction). It appears to be a special case.\r\n\r\nThe reduction is straightforward, however. I simply keep a hash table of the earliest depth a position was seen in, in 96-symmetry, for small depths, and never explore from a position already seen. For Reid\'s position, this gives you a reduction in symmetry that increases as the depth you keep the hash table to increases (QTM below):\r\n\r\n
\r\nAt depth 0 saw 1 out of 1 red 1 elim 0\r\nAt depth 1 saw 2 out of 12 red 6 elim 10\r\nAt depth 2 saw 10 out of 114 red 11.4 elim 22\r\nAt depth 3 saw 34 out of 1068 red 31.4118 elim 84\r\nAt depth 4 saw 220 out of 10011 red 45.5045 elim 188\r\nAt depth 5 saw 1519 out of 93840 red 61.7775 elim 735\r\nAt depth 6 saw 11697 out of 879624 red 75.2008 elim 3328\r\nAt depth 7 saw 93536 out of 8245296 red 88.151 elim 19393\r\nAt depth 8 saw 771072 out of 77288598 red 100.235 elim 124841\r\nAt depth 9 saw 6476518 out of 724477008 red 111.862 elim 873434\r\n\r\n\r\nNote that it is critical to eliminate the antisymmetric cases. If you don\'t do that you only get:\r\n\r\n
\r\nAt depth 0 saw 1 out of 1 red 1 elim 0\r\nAt depth 1 saw 2 out of 12 red 6 elim 10\r\nAt depth 2 saw 12 out of 114 red 9.5 elim 20\r\nAt depth 3 saw 74 out of 1068 red 14.4324 elim 63\r\nAt depth 4 saw 656 out of 10011 red 15.2607 elim 115\r\nAt depth 5 saw 5934 out of 93840 red 15.814 elim 368\r\nAt depth 6 saw 55156 out of 879624 red 15.9479 elim 1015\r\nAt depth 7 saw 514037 out of 8245296 red 16.0403 elim 4397\r\nAt depth 8 saw 4796804 out of 77288598 red 16.1125 elim 27244\r\n\r\n\r\nBut this is apparently pretty rare; only a few positions yield more search space reduction than their symmetries.','64.160.186.130',1139876216,0,0,'1.1.1.1.1/','a:1:{i:0;i:0;}'),(173,170,40,39,'Right after I posted that com','Right after I posted that comment, I went for a run with the yellow Labrador, and during that run I figured out that the edge orientation, flipping with each quarter turn, would indeed preserve M-symmetry. Thanks for the confirmation!\r\n\r\nOn the corner orientation, how did you figure that to be the best you could do? Is there a lengthy explanation somewhere? I\'ve been working through some candidate coordinates and have not been able to come up with a better one. Do you have a concise description of what the coordinate is, exactly? I.e., what moves generate what twists?','64.160.186.130',1139876492,0,0,'1.1.1.1.2.1.1/','a:1:{i:0;i:0;}'),(174,173,40,28,'No, I have no really bulletpr','No, I have no really bulletproof argumentation, that this is the best.\r\n\r\nCoordinates correspond to right cosets of a certain subgroup H of the cube group G. The usual corner orientation coordinate is defined by the subgroup H, which keeps all corner orientation =0. If the coordinate should be able to be transformed to a sym-coordinate, this only is possible, if the subgroup H is invariant under conjugation with all elements of symmetry group. If this symmetry group is M, then for all x in M we must have x^-1 H x=H.\r\n\r\nThis is not valid with the corner orientations defined in the usual way, where H =[U,U2,U\',D,D2,D\',R2,F2,L2,B2].\r\n\r\nBut with the \"extended\" corner coodinate which also takes into account the position of the four \"tetraeder corners\", the corresponding subgroup H is defined by all elements of G, where the orientations stay 0 *and* all corners stay in their tetraeder. This subgroup has 4!*4! = 576 elements (ignoring the edges), and the number of cosets is 8!*3^7/576, which is the 70*2187. And H is invariant under conjugation by all 48 symetries.\r\n\r\nBut I have no strict proof, that there is no possibility to define the orientations in different way so that there is a smaller number of cosets which respect M-symmetry.','217.224.105.190',1139954206,0,0,'1.1.1.1.2.1.1.1/','a:1:{i:0;i:0;}'),(175,60,26,39,'I have verified these numbers','I have verified these numbers with a totally separate program. Great work, Bruce!','63.197.151.31',1140251012,0,0,'2.3.1.1/','a:1:{i:0;i:0;}'),(176,175,26,31,'Re: I have verified these numbers','Thank you for verifying my results, Tom. So I assume you verified both QTM and FTM, since you didn\'t give any details about what you did.\r\n\r\nBy the way, have you considered trying this analysis with a different edge orientation convention, such as the one used in Mike Reid\'s program? That doesn\'t allow full M-symmetry to be used, but I speculate that it may result with a higher average distance. But it also has a cost of approximately 3 times the number of \"real\" positions.\r\n\r\n - Bruce Norskog','70.22.162.179',1140300956,0,0,'2.3.1.1.1/','a:1:{i:0;i:0;}'),(177,176,26,39,'Yep, did both QTM and FTM.\r\n\r','Yep, did both QTM and FTM.\r\n\r\nI\'m confused how a different edge orientation convention would change the average distance? Wouldn\'t it by necessity yield precisely the same numbers?','63.197.151.31',1140325506,0,0,'2.3.1.1.1.1/','a:1:{i:0;i:0;}'),(178,177,26,31,'edge orientation convention and distance distributions','
In the absence of sufficient information about which edge cubie is where, I believe it does make a difference what edge orientation convention is used. In this case, there is no information about the permutation of the edges. Try doing God\'s algorithm calculations where only edge orientation is considered (2048 positions). Try different edge orientation conventions (such as Reid\'s convention and an M-symmetric convention) and see if the results have the same distribution. (I just tried this myself, and if my quickly hacked program worked correctly, the results are close, but not exactly the same.)
\r\n\r\nI remember awhile back I tried duplicating Mike Reid\'s pruning table with my own code. I ran my program and compared the distribution of distances with those given by Reid\'s program. My results were different, so I assumed I must have had a bug in my program. After analyzing the discrepancy, I concluded that the reason my results were different was not because my program was working incorrectly, but because I was defining edge orientation differently. I believe I had totally correct results, but for a different subgroup. After changing the edge orientation convention, I got the same results. I suspect Mike Reid chose the edge orientation that he did because of the quality of the resulting pruning table.
\r\n - Bruce Norskog','70.22.162.179',1140385084,0,0,'2.3.1.1.1.1.1/','a:1:{i:0;i:0;}'),(179,0,32,39,'This seems to happen to these','This seems to happen to these types of forums quite frequently. I\'d recommend as much as possible keeping frequent backups somewhere, and as much as possible be comfortable with wiping the machine and installing everything from scratch. This is a great resource and I\'d hate for it to disappear.\r\n\r\nBy the way, is there an easy way to see if there are any new comments, even in some of the older articles?','63.197.151.31',1140536636,0,0,'1/','a:1:{i:0;i:0;}'),(180,179,32,1,'I make monthly backups','...but I\'m going to start doing weekly backups. There is a way to let users track new events but when I turned it on something very bad happened and messed up the site. Fortunately I made a backup immediately before I changed the modules. Looks like I may have to setup a test site to figure out what went wrong. Your comment about backups is well taken and this site exists largely because I was worried about the original cube-lovers archives disappearing. \r\n\r\nRest assured I have many backups of this site. Soon I will post the mysql backups on the net. Once I am sure it won\'t break anything I\'ll turn tracking on for users. Until then just do a quick scan through the pages and the new articles should have a red \"new\" to the top right.','127.0.0.1',1140546488,0,0,'1.1/','a:1:{i:0;i:0;}'),(181,0,46,34,'Congratulations Bruce. I have','Congratulations Bruce. I have been looking foward too see this for some time. However I was convinced that there will be more antipodes. It is also interesting to note that for your both computations the diameter was the same as for the edges only.','213.112.65.47',1140560052,0,0,'1/','a:1:{i:0;i:0;}'),(182,0,45,39,'Wow, that\'s great!\r\n\r\nI\'m jus','Wow, that\'s great!\r\n\r\nI\'m just wrapping up a big set of 20-move positions, proving that they are local (nonstrict) maxima.\r\n\r\nIs the time you give above (within a day) and (within about 4 days) for the entire set, or for each cube? I.e., how long did it take your optimal solver to find each 20-move solution?\r\n\r\nDo you plan to check if they are local maxima?','64.160.186.130',1140568992,0,0,'1/','a:1:{i:0;i:0;}'),(183,0,45,39,'Hmm, all these positions are','Hmm, all these positions are congruent (mod M) to their own inverse. Is that expected?','64.160.186.130',1140570479,0,0,'2/','a:1:{i:0;i:0;}'),(184,182,45,28,'It is the time for the whole','It is the time for the whole set. With the four days I am not totally sure, could also be 5 or 6 days - I do not write down when I started the computation.','217.224.127.46',1140580101,0,0,'1.1/','a:1:{i:0;i:0;}'),(185,183,45,28,'The first 26 are selfinverse,','The first 26 are selfinverse, for the other 13 a point reflection at the cube center gives the inverse. I only can state this - it was expected in no way.','217.224.127.46',1140580509,0,0,'2.1/','a:1:{i:0;i:0;}'),(186,184,45,39,'That\'s still stunningly fast;','That\'s still stunningly fast; 39 20-optimal solutions in only a few days.','63.197.151.31',1140586659,0,0,'1.1.1/','a:1:{i:0;i:0;}'),(187,169,40,31,'A possible improvement','This appears to me to be a good idea, Tom.\r\nThanks for sharing.
\r\n\r\nWhen working with M-symmetric problems, I have been subdividing the twelve edges based upon which inner slice each belongs to, rather than subdividing according to which of three parallel slices they belong to.\r\nSo my four most-significant edges are UF, UB, DF, and DB.\r\nWith this convention, it appears to me your technique could be modified so that the code could iterate over 3 inner slices, rather than 6 faces.\r\nThe lookups would provide a best of 16 rather than a best of 8.\r\nIt seems to me this may provide another 2x improvement (approximately) in speed.
\r\n\r\nI have been looking at optimizing my code for iterating over my distance table of corner and edge permutations and tabulating only the representatives (unique wrt M and unique wrt M+inv).\r\nSince in my case, the edge permutation is considered less significant than the corner permutation, I must restrict the elements of M used to those that do not affect the value of the corner permutation.\r\nSo this technique doesn\'t look like it would work for my immediate need, since I need to consider different subsets of the 16 possibilities depending upon what corner permutation I am working on, rather than getting the best of all 16.
\r\n','70.22.162.179',1140671940,0,0,'1.1.1.1.2.2/','a:1:{i:0;i:0;}'),(188,181,46,31,'More info on the FTM antipodes','Yes, I was well aware that the diameters in both metrics are the same as for the edges only analysis. I guess I was a little surprised at the result that after the peak distance, how high a percentage of the remaining positions were just 1 more move deep.
\r\nI will note that none of the deep positions (17q, 18q) in QTM are antipodes in FTM. There are some corner configurations in common and at least one edge configuration in common.\r\nThe following table shows these deep QTM positions and optimal sequences for them in FTM.
\r\n\r\n Distance\r\n CP EP QTM FTM FTM Move Sequence\r\n----- --------- --- --- -----------------\r\n 54 130377481 17q 13f U\' D2 B\' R U2 R\' F2 B\' R F\' L2 B\' U\'\r\n 127 163710727 17q 13f U R\' F R2 U R\' D2 F\' R U2 R\' U B2\r\n 415 3653859 17q 13f U D\' R F L2 D\' R2 U R\' D2 F2 D R\'\r\n 4761 123758783 17q 13f U R U2 D\' L2 U2 F\' B2 L2 D\' L\' U F2\r\n 5209 127387463 17q 13f U B2 U2 L B R\' L B\' R\' D2 B2 D\' R\'\r\n 9800 127389022 17q 12f U\' L2 U2 L U\' R2 F\' L2 B2 D2 F\' U2\r\n 9800 127390445 17q 13f U2 B\' U D2 F2 L D\' B2 D F\' B R\' U\'\r\n12322 299547493 17q 13f U F\' B\' U R2 L2 U\' R2 L2 D\' R L D\'\r\n14128 409720015 17q 11f U2 D2 R2 U\' L2 F\' B U2 L U2 F\'\r\n14128 449636809 17q 12f U D\' L2 D2 F B L2 U\' B2 R\' L D2\r\n14854 248577983 17q 13f F U2 B\' R2 F\' U B2 R\' U\' L U2 D B\'\r\n35152 127387583 18q 13f U D F2 R\' U2 F B\' L2 U\' R L\' B2 R2\r\n\r\n
I have also determined that all of the antipodes in the FTM analysis have symmetry.\r\nThe table below shows the corner, edge, and overall symmetries for the antipodes. It also shows the order of the positions along with the order of the corner and edge configurations of the positions.
\r\n\r\n\r\nFTM Antipode (14f) positions in corner and edge permutations analysis\r\n\r\n Position Symmetries Order\r\n CP EP C E All C E All Move sequence\r\n----- --------- -- - --- - -- --- -------------\r\n 54 3662626 12 8 4 2 2 2 U D R\' B\' D\' L2 D F B D2 F D2 L B\r\n 54 123766418 12 8 4 2 2 2 U D B\' U2 D2 B2 R\' U B U2 R2 D B\' L\'\r\n 150 3657583 4 4 4 4 2 4 U D F U\' F2 L\' B L\' U F\' D2 F\' D\' B2\r\n 150 3663952 4 4 4 4 2 4 U D F L U D2 B\' D\' L\' B D2 F2 U\' B\r\n 168 3645909 4 4 4 4 4 4 U D F B L2 U D R\' F\' B\' U D F\' B\'\r\n 294 3653138 4 8 4 4 2 4 U D2 F2 U2 L U2 B\' U R F2 L2 D\' F U2\r\n 294 3658179 4 4 4 4 4 4 U D F D R B\' L B U2 R F B L D\'\r\n 949 299576877 6 6 6 6 6 6 U D F\' U\' R U\' D B L\' F D R2 L\' F\'\r\n 5176 16687 4 8 4 2 2 2 U D\' R L\' D2 R F\' B\' R2 U2 R\' L\' B\' L2\r\n 5209 123771602 4 4 4 4 4 4 U D R U D2 F B2 U R U2 R L U R\'\r\n 6068 127387583 2 48 2 6 2 6 U D2 B D\' B2 U R L2 B R2 F2 R2 U\' B\r\n 6754 119761927 2 4 2 8 4 8 U D B2 R F\' U F U F\' R2 D2 F\' D\' R\r\n 9682 40291210 4 8 4 8 4 8 U D2 F B U\' F2 B2 D R2 L2 U\' R L D\'\r\n 9758 127400524 8 4 4 4 4 4 U D R2 F\' R\' L F2 R2 F B R\' B2 U2 R2\r\n 9800 123771724 4 4 4 4 4 4 U D2 R\' U2 F2 D R B L D\' F L2 F\' B2\r\n14385 118721486 6 2 2 6 12 12 U D B U\' L D B\' L\' F2 L\' B2 R U B2\r\n14385 179448349 6 6 6 6 12 12 U F U R2 F D F\' L2 U2 D R2 L\' U B2\r\n35152 127427927 48 3 3 2 6 6 U F\' D\' R2 U\' F\' D2 F2 U\' L2 F2 L2 D B\r\n\r\n','70.22.162.179',1140738930,0,0,'1.1/','a:1:{i:0;i:0;}'),(189,0,45,39,'Is it possible for me to get','Is it possible for me to get a list of *all* of your distance 20 positions that you\'ve proven? I can grab the list from this article and your prior one, but you mention they are not complete. If you give me this I\'ll add my list to it and put it up somewhere. Thanks!','63.197.151.31',1140798722,0,0,'3/','a:1:{i:0;i:0;}'),(190,189,45,28,'Please give me your email add','Please give me your email address. If you do not want to give it here, send it to my email address given on my homepage.','217.224.117.233',1140823372,0,0,'3.1/','a:1:{i:0;i:0;}'),(191,190,45,39,'Email','I\'m rokicki at gmail.com. I\'ve already started on the ones you posted (I\'m solving all the neighbors optimally because I\'m interested in any nearby distance-20 cubes as well). Right now I have a total of 174 distance-20 positions (mod M + inv); I look forward to getting more!\r\n\r\nFor the neighbors I\'ve run so far for the set I have (over 700 unique neighbors), almost all are at distance 19, and only a couple are at distance 20.\r\n\r\nOnce I add yours I\'d be happy to share the database around if anyone else is interested.','63.197.151.31',1140825958,0,0,'3.1.1/','a:1:{i:0;i:0;}'),(192,0,46,31,'Symmetry- and antisymmetry-reduced numbers','
I have now calculated the number of positions that are unique with respect to the symmetries of the cube, and the number of postions that are unique with respect to the symmetries of the cube and inverses.
\r\n\r\nPermutations of the corners and edges of the\r\n3x3x3 Rubik\'s Cube, ignoring orientation\r\n\r\nDistance Positions Unique wrt M Unique wrt M+inv\r\n-------- --------- ------------ ----------------\r\n 0f 1 1 1\r\n 1f 18 2 2\r\n 2f 243 9 8\r\n 3f 3,240 75 48\r\n 4f 43,239 934 509\r\n 5f 574,308 12,066 6,194\r\n 6f 7,599,538 158,743 79,988\r\n 7f 100,336,092 2,091,849 1,048,365\r\n 8f 1,320,811,484 27,521,978 13,771,573\r\n 9f 17,277,892,377 359,974,828 180,038,239\r\n 10f 220,284,799,718 4,589,335,308 2,294,966,955\r\n 11f 2,346,113,524,904 48,877,623,050 24,440,810,817\r\n 12f 6,808,973,777,807 141,854,272,251 70,934,468,707\r\n 13f 262,592,892,783 5,470,812,680 2,736,830,237\r\n 14f 248 18 17\r\n ----------------- --------------- ---------------\r\n 9,656,672,256,000 201,181,803,792 100,602,021,660\r\n\r\n - Bruce Norskog','70.22.129.10',1140896952,0,0,'2/','a:1:{i:0;i:0;}'),(193,188,46,23,'I am probably saying the same','I am probably saying the same thing in slightly different way, but it\'s very interesting how short the tail of the distribution is, and how severe the drop-off is between the peak and the end of the tail.\r\n\r\nEssentially every finite combinatorial puzzle seems to have the same sort of distribution -- a gradual rise to a peak with a relatively constant branching factor, and then the distribution has a relatively short tail after the peak.\r\n\r\nIn the case of Rubik\'s cube, the face turn metric seems to have a very severe droppoff and a very short tail. It seems likely to me that the diameter of the group in the face turn metric is greater than 20, but it also seems unlikely to be much more than 20.','198.146.200.207',1141077746,0,0,'1.1.1/','a:1:{i:0;i:0;}'),(194,193,46,28,'For me it is very interesting','For me it is very interesting to observe \r\n that it is also the number of positions distribution in % which \r\n is really almost identical for the full cube and the cube ignoring \r\n orientations when we just shift 6 moves, taking the simulation \r\n of Tom Rokicki with random cubes for15f to 20f and Jerry Bryans \r\n computation for 0f to 10f. I have no doubts, that this also \r\n holds for 11f to 14f and little doubts that this also holds \r\n for >= 20f.
Full Cube | \r\n Cube without orientations | \r\n ||||
| \r\n 6f | \r\n \r\n | 1.7*10-11% | \r\n 0f | \r\n 1 | \r\n 1.0*10-11% | \r\n
| \r\n 7f | \r\n \r\n | 2.3*10-10% | \r\n 1f | \r\n 18 | \r\n 1.9*10-10% | \r\n
| \r\n 8f | \r\n \r\n | 3.1*10-9% | \r\n 2f | \r\n 243 | \r\n 2.5*10-9% | \r\n
| \r\n 9f | \r\n \r\n | 4.1*10-8% | \r\n 3f | \r\n 3,240 | \r\n 3.4*10-8% | \r\n
| \r\n 10f | \r\n \r\n | 5.4*10-7% | \r\n 4f | \r\n 43,239 | \r\n 4.5*10-7% | \r\n
11f | \r\n \r\n | \r\n | 5f | \r\n 574,308 | \r\n 5.9*10-6% | \r\n
12f | \r\n \r\n | \r\n | 6f | \r\n 7,599,538 | \r\n 7.9*10-5% | \r\n
13f | \r\n \r\n | \r\n | 7f | \r\n 100,336,092 | \r\n 0.001% | \r\n
14f | \r\n \r\n | \r\n | 8f | \r\n 1,320,811,484 | \r\n 0.014% | \r\n
| \r\n 15f | \r\n 37 | \r\n 0.16% | \r\n 9f | \r\n 17,277,892,377 | \r\n 0.18% | \r\n
| \r\n 16f | \r\n 579 | \r\n 2.5% | \r\n 10f | \r\n 220,284,799,718 | \r\n 2.2% | \r\n
| \r\n 17f | \r\n 6,062 | \r\n 26% | \r\n 11f | \r\n 2,346,113,524,904 | \r\n 24% | \r\n
| \r\n 18f | \r\n 15,263 | \r\n 67% | \r\n 12f | \r\n 6,808,973,777,807 | \r\n 71% | \r\n
| \r\n 19f | \r\n 811 | \r\n 3.5% | \r\n 13f | \r\n 262,592,892,783 | \r\n 2.7% | \r\n
| \r\n 20f | \r\n 0 | \r\n 0% | \r\n 14f | \r\n 248 | \r\n 2.6*10-9% | \r\n
| \r\n | \r\n | \r\n | \r\n | -------------------- | \r\n \r\n |
| \r\n | \r\n | \r\n | \r\n | 9,656,672,256,000 | \r\n \r\n |
I have calculated the number of positions for each combination\r\nof QTM distance and FTM distance for the permutations of the corners\r\nand edges (ignoring orientation) analysis. I have done it for overall\r\npositions, positions unique with respect to symmetries of the cube,\r\nand positions unique with respect to symmetry and inverses.\r\nWhile tables like this generally put FTM on one axis and QTM on the\r\nother axis, to keep the table of reasonable width, I have included a\r\ncolumn for giving the combination of FTM and QTM distances, and the other\r\ncolumns providing the corresponding position counts.
\r\n\r\nPermutations of the corners and edges of the\r\n3x3x3 Rubik\'s Cube, ignoring orientation\r\n\r\nFTM/QTM\r\ndistance Positions Unique wrt M Unique wrt M+inv\r\n-------- --------- ------------ ----------------\r\n0f,0q 1 1 1\r\n1f,1q 12 1 1\r\n1f,2q 6 1 1\r\n2f,2q 108 4 4\r\n2f,3q 108 3 2\r\n2f,4q 27 2 2\r\n3f,3q 960 22 15\r\n3f,4q 1440 32 19\r\n3f,5q 720 16 10\r\n3f,6q 120 5 4\r\n4f,4q 8544 185 109\r\n4f,5q 17088 362 185\r\n4f,6q 12816 277 154\r\n4f,7q 4272 92 48\r\n4f,8q 519 18 13\r\n5f,5q 76032 1600 836\r\n5f,6q 189528 3967 2015\r\n5f,7q 189504 3966 2022\r\n5f,8q 94224 1990 1029\r\n5f,9q 23088 487 254\r\n5f,10q 1932 56 38\r\n6f,6q 675492 14130 7216\r\n6f,7q 2017728 42090 21087\r\n6f,8q 2518200 52553 26503\r\n6f,9q 1664160 34728 17409\r\n6f,10q 608898 12797 6520\r\n6f,11q 109536 2303 1166\r\n6f,12q 5524 142 87\r\n7f,7q 5986392 124880 62807\r\n7f,8q 20879088 435190 217958\r\n7f,9q 31251456 651340 326244\r\n7f,10q 25805490 537946 269487\r\n7f,11q 12559632 261826 131224\r\n7f,12q 3432000 71827 36170\r\n7f,13q 413772 8638 4357\r\n7f,14q 8262 202 118\r\n8f,8q 52913512 1102844 552892\r\n8f,9q 211597104 4408868 2205254\r\n8f,10q 370234974 7714227 3860474\r\n8f,11q 368018376 7667952 3835193\r\n8f,12q 224091580 4669598 2337447\r\n8f,13q 80300580 1673244 837065\r\n8f,14q 13333648 278521 139856\r\n8f,15q 321672 6720 3388\r\n8f,16q 38 4 4\r\n9f,9q 465606300 9701400 4854820\r\n9f,10q 2117692320 44120720 22066364\r\n9f,11q 4295845096 89500251 44761704\r\n9f,12q 5105816534 106375867 53200761\r\n9f,13q 3739132476 77901404 38960088\r\n9f,14q 1414756983 29478191 14745115\r\n9f,15q 139015284 2896376 1449052\r\n9f,16q 27384 619 335\r\n10f,10q 4051435966 84408572 42220275\r\n10f,11q 21536942020 448694176 224376182\r\n10f,12q 53740362543 1119607519 559887452\r\n10f,13q 78564080056 1636768834 818460665\r\n10f,14q 52346691627 1090576272 545367765\r\n10f,15q 10040117420 209171969 104600351\r\n10f,16q 5170086 107966 54265\r\n11f,11q 33548531432 698936801 349528714\r\n11f,12q 252432622044 5259046844 2629729367\r\n11f,13q 855359575472 17820068930 8910724709\r\n11f,14q 920366072402 19174398757 9587899025\r\n11f,15q 284134407796 5919497275 2960086739\r\n11f,16q 272315746 5674442 2842262\r\n11f,17q 12 1 1\r\n12f,12q 195315571574 4069096245 2034734512\r\n12f,13q 1911512441880 39823320487 19913400209\r\n12f,14q 3206355450152 66799362228 33402523135\r\n12f,15q 1492949068428 31103293624 15554155858\r\n12f,16q 2841245737 59199665 29654991\r\n12f,17q 36 2 2\r\n13f,13q 43840406436 913357167 456875687\r\n13f,14q 130857519042 2726244685 1363584202\r\n13f,15q 87496405308 1822904039 912191911\r\n13f,16q 398561824 8306780 4178428\r\n13f,17q 172 8 8\r\n13f,18q 1 1 1\r\n14f,14q 12 1 1\r\n14f,15q 184 14 13\r\n14f,16q 52 3 3\r\n ------------- ------------ ------------\r\n 9656672256000 201181803792 100602021660\r\n\r\n','70.22.129.10',1141353065,0,0,'2.1/','a:1:{i:0;i:0;}'),(196,0,47,34,'I can say that the actual low','I can say that the actual lower bound is 20f. \r\nThe 901 quadrilion number means how many equivalence classes there are when the group M acts on the cube by conjugation. This action has the property that the elements in an equivalence class have the same length. This number is reduced to half if you also allow inversion see the Godfrey Kociemba article on this forum. \r\n','213.112.65.21',1141679392,0,0,'1/','a:1:{i:0;i:0;}'),(197,0,48,39,'Excellent work! I wonder how','Excellent work! I wonder how much more effort it would be to get complete distance distributions for the symmetry classes, since you\'ve already optimally solved the hard ones? Also, do you have a summary table for all the symmetry classes you\'ve explored, listing the name of the class, the count of elements (maybe broken into antisymmetric and not antisymmetric), and the number that were at distance 20?\r\n\r\nPersonally, I think that while most 20\'s we\'ve found are symmetric, that most positions at length 20 will not be (since there are *so* many more non-symmetric positions than symmetric positions, this will overcome the greater tendency of the symmetric positions to be at a large distance). On the other hand, most tails of the subgroups, cosets, and other classes we have explored have been symmetric positions, so maybe I\'m wrong.','64.160.186.130',1141844617,0,0,'1/','a:1:{i:0;i:0;}'),(198,197,48,28,'I always run the two-phase-so','I always run the two-phase-solver over the complete set telling it to stop when it finds a 19-move solution. For maybe 10% of the cubes the search does not stop within a few days, so for analyzing 30000 cubes there are about 3000 cubes which I have to solve optimally. This takes another few days. If I want to solve all cubes optimally, with an average of maybe 1-2 minute/cube (I actually did not verify this, may also be more) this would take 30000 minutes which would be about three weeks or more. So I content myself with just finding the antipodes in the moment.\r\n\r\nI did not make any statistics yet for all the classes. I will try to finish the computations for the 4-symmetries first.\r\n\r\nI also have your opinion that there are many more unsymmetric 20\'s than symmetric. I estimate more than 1,000,000,000 20f* cubes. That the tails of all distributions we know have significantly many cubes with a higher degree of symmetry is no contradiction to this. But I think it is highly improbable that *all* the antipodes will have less than 4 symmetries. So if we do not find any 21f* cube with 4 symmetries I think we never will find any 21f* cube at all.','217.224.97.148',1141857380,0,0,'1.1/','a:1:{i:0;i:0;}'),(199,0,45,41,'Queastion regarding the Process','Do you compare each cube with te previous optimal cubes to determine whether it is optimal or do you have another way of determining optimality? \r\n\r\nIf you are comparing with the previous optimal solutions, do you have an available database for those?','202.138.180.35',1141891324,0,0,'4/','a:1:{i:0;i:0;}'),(200,191,45,41,'May I also have a copy of that?','my email address is demented_kat11@yahoo.com','202.138.180.35',1141891557,0,0,'3.1.1.1/','a:1:{i:0;i:0;}'),(201,196,47,41,'Clarifications','1.)what is group M?\r\n\r\n2.)Regarding equivalence classes, does it mean, for example that LRU and R\' LRU R are of the same equivalence classes?\r\n\r\nI\'m really sorry, i\'m hopelessly a nooB... ','202.138.180.35',1141891921,0,0,'1.1/','a:1:{i:0;i:0;}'),(202,201,47,34,'An equivalence class containi','An equivalence class containing a certain elemet x in the cube group contains all elements m\'xm with m in M. Typically 48 elements because the group M has 48 elements. For a general definition of an equivalence class you can consult the Mathworld site. \r\nYou can define the generators of the cube in GAP i.e. U,L,F,B,R,D. And you can also define the generators of M. There is a post about this on the forum submitted by Joe Miller. In the comment of this post I submitted the generators of M with respect to the generators I use. If you conjugate a generator by an element of M then you get another generator of the cube.','213.112.65.21',1141893454,0,0,'1.1.1/','a:1:{i:0;i:0;}'),(203,199,45,28,'I recommend to take a look at','I recommend to take a look at my homepage at\r\n\r\nhttp://kociemba.homepage.t-online.de/cube.htm\r\n\r\nfor more details on suboptimal and optimal solving of the cube. But optimal solving of a cube has nothing to do with optimal solving of other cubes in this connection. ','217.224.86.201',1141910234,0,0,'4.1/','a:1:{i:0;i:0;}'),(204,201,47,2,'To expand just a little bit m','To expand just a little bit more -- I\'ll try not to introduce any inaccuracies...\r\n\r\n> 1.)what is group M?\r\n\r\nIt is the group of geometrical symmetries of an ordinary cube (or a solved Rubik\'s Cube): the 48 rotations and reflections. An equivalence class defined [as above] via conjugation by elements of M is a set of positions that are \"the same\" as one another, apart from rotation or reflection. So the set of all equivalence classes is in 1-to-1 correspondence with the set of \"distinct\" positions of the Cube; i.e., a minimal set of positions, none of which is related to another by symmetry. This is why people refer to the \"real\" size of Cube space in this context.\r\n\r\n> 2.)Regarding equivalence classes, does it mean, for example that LRU and R\' LRU R are of the same equivalence classes?\r\n\r\nConjugation by the elements of the Cube group (with ~4e19 elements) itself could ALSO be used to define equivalence classes, but they would not be the same as the ones referred to above. In this case, the members of an equivalence class would all have the same cycle structure. ','130.88.128.98',1141992140,0,0,'1.1.2/','a:1:{i:0;i:0;}'),(205,202,47,41,'oh...','Thank you so much for the clarifications. :)\r\n','203.87.188.198',1142179938,0,0,'1.1.1.1/','a:1:{i:0;i:0;}'),(206,157,42,39,'I believe there is a strong c','I believe there is a strong correlation between antisymmetry and maneuver length; almost all the 20f* cubes we\'ve found have been antisymmetric, but very few random cube positions are antisymmetric.\r\n','64.160.186.130',1142269331,0,0,'1.1.1.1.1.1.2.1.1.1.1.1/','a:1:{i:0;i:0;}'),(207,0,49,34,'Mark I have submitted this bu','Mark I have submitted this but can not change it. Could you replace \"in the group\" with \"in the group < U,D,L^2,F^2,B^2,R^2 >.\" Thanks in advance. ','213.112.65.21',1142411843,0,0,'1/','a:1:{i:0;i:0;}'),(208,207,49,1,'Made a minor edit','I made a minor edit replacing the less than symbol and greater than symbol with their html equivalents.\r\n\r\nI don\'t think using \"<\" and \">\" works too well without double quotes around them so perhaps using the html version is better. Everything after that looked a bit mangled but it looks ok now.','127.0.0.1',1142414004,0,0,'1.1/','a:1:{i:0;i:0;}'),(209,208,49,34,'Thank you for the improvement','Thank you for the improvement. I will keep that in mind.','213.112.65.21',1142415059,0,0,'1.1.1/','a:1:{i:0;i:0;}'),(210,0,49,39,'This is absolutely amazing; o','This is absolutely amazing; over 19B cubes optimally solved. That\'s a pretty big fraction of the entire cube space! I think this is the first time such a big chunk has been explored (at least, a chunk that doesn\'t implicitly exclude deep cubes).','64.160.186.130',1142460530,0,0,'2/','a:1:{i:0;i:0;}'),(211,0,49,28,'How did you manage to do this','How did you manage to do this? You surely did not run the optimal solver over each of these positions one by one. But I also do not see how for example a breadth first search could be done here.','217.224.82.187',1142516522,0,0,'3/','a:1:{i:0;i:0;}'),(212,211,49,39,'It\'s a simple coset search.','It\'s a simple coset search. He simply uses a pruning table (in this case the standard U/D/F2/B2/R2/L2 table) to guide an iterative deepening search; for each solution found, he indexes the whole-cube position and looks it up in a big bit vector; if this is the first time that whole-cube solution was found, that\'s an optimal solution for this cube. It\'s the same approach I used for my edge space searches, only much larger (solving many more cubes at a time) and much faster (because this pruning table is much faster than the whole edgespace pruning table).\r\n\r\nI\'m jealous; I didn\'t think such an approach would complete in any reasonable amount of time. I\'m hoping he posts more about this search here.','64.160.186.130',1142525479,0,0,'3.1/','a:1:{i:0;i:0;}'),(213,211,49,34,'In order to explain it in a e','In order to explain it in a easy way:\r\n\r\nLet us now consider a standard optimal solver like Reid\'s. How does it work? Giving it an arbitrary position it finds out in which coset it is. Then he finds maneuvers that takes this coset to the identity coset. However this maneuvers need not to solve the position but they allways take the position into the target group H. This should be well known. \r\n\r\nSo actually what Reids solver does for each depth is that it finds all solutions that take the given position that we want to solve to the identity coset. Normally we stop when the maneuver is taken to identity itself. \r\n\r\nHere we introduce a bit vector that registers all solutions to the identity coset and in this way we find for each depth each solution from the position in question to the identity coset. If we choose as position to solve the identity\r\n(Reids solver will stop direct but we modify it so that it continues)\r\n and let the solver run through all depths we get the above table.\r\n\r\nTo repeat all of this in other words the solver will then begin from identity and find all solutions of length 0 that takes the identity to the group H. \r\nNext he finds all solutions of length 1 that takes the identity to the group H and so on.\r\nAnd once a solution is found we mark in the bit vector the element in the group H in question.\r\n\r\n','213.112.65.21',1142526240,0,0,'3.2/','a:1:{i:0;i:0;}'),(214,0,49,34,'Tom encouraged me to post som','Tom encouraged me to post some more details about this.\r\nFirst of all. I run as we both described up to depth 21. This took 130 hours on an 2.53Ghz AMD Opteron with 1Mb cache. 3x faster than a P4.\r\nI listed all remaining odd positions i.e. depth 23,25,27...\r\nI took each position multiplied it by either U2,L2,F2,B2,R2,D2. And if the new element took me out of the remaining odd set then this position had depth 23. This allowed me to find all depth 23 positions.\r\nThan I continued in the same manner as Tom and I described with depth 22 but did not run it to completion. I run it until there where 476 even positions left. I took each position multiplied it by either U,D,U3,D3 and saw if it takes me to depth 23 if not then it must be depth 22. I was left with 5 pos unique M+inv that I run optimally.\r\nAnd so the result.\r\nthe partial depth 22 took about 100 hours. So total runtime and all say 300 hours.\r\n\r\n','213.112.65.21',1142529518,0,0,'4/','a:1:{i:0;i:0;}'),(215,210,49,31,'the fraction of cube space','
As there are two other obvious subgroups isomorphic to this subgroup, I believe this effectively means approximately 3 times as many positions can be regarded as having been solved. That\'s about 58*10^9 out of the 43*10^18 positions. I believe it corresponds to about 600 million positions unique wrt M+inv (out of approx. 450*10^15). Either way, it\'s more than 10^-9 of cube space! Right?
\r\n\r\nAnother note: the 24q* position is 16f* (U B2 U B2 D\' F2 D L2 U F2 U\' F2 U R2 F2 U\') according to Cube Explorer (3.67). I\'ll note that almost all the positions in the subgroup can be solved in 16f or less without even leaving the subgroup, so I guess 16f* should not be surprising. (1575608 positions 17f and 1352 positions 18f, staying within the subgroup. This means solving using only U,U\',U^2,D,D\',D^2,L^2,R^2,F^2, and B^2. Optimal FTM solving would reduce these numbers further. The numbers are from a Michael Reid post on the old Cube-lovers mailing list.) The 24q* position has order 4, meaning that if you perform either the 24q* or 16f* sequence 4 times in succession, you get back to the starting position.
\r\n','70.22.157.222',1142551884,0,0,'2.1/','a:1:{i:0;i:0;}'),(216,0,29,23,'Several comments about Moore\'','Several comments about Moore\'s law:\r\n\r\n1. The end of Moore\'s law has been predicted several times before. And each time a technology breakthrough of some sort rescued Moore\'s law for a few more years. I think we are on a cusp where Moore\'s Law is once again at some considerable risk. The fundamental problem at this point is not that electronic components can\'t be made smaller and faster. The fundamental problem right now is heat. The faster is a computer\'s clock cycle, the more heat it generates. Indeed, the next big idea from Intel (for one example) is to make their chips run slower rather than faster. In order to continue to make computers more powerful, a single chip will (and any many cases already has) more than one processor per chip. This technique has the name multi-core chip (I don\'t understand the name multi-core -- I would call it a multi-processor chip -- but Intel seems to identify the concept of a chip with the concept of a processor).\r\n\r\n2. Moore\'s law was never about the speed of the chip. It was always about the density of circuits on a chip -- making transistors and other circuit components smaller, if you will. In that respect, Moore\'s law may continue for quite a few more years before it runs into some fundamental physical barrier. Of course, making circuits smaller generally speaking allows them to run faster -- until you get to the point that there is more heat than can be dissipated. Maybe we just need to water cool (or even liquid nitrogen cool) our desktop PC\'s.\r\n\r\n3. For many years, Apple had a policy that they would never make a computer that required a fan -- fan noise is uncool and all devices manufactured by Apple had to be cool (c.f. the iPod). But Apple long since has had to abandon that policy because faster chips couldn\'t be cooled any other way.\r\n\r\n4. The bottom line right now is that Moore\'s law may continue for quite a few more years in terms of circuit density, but that doesn\'t mean that individual processors are going to get much faster than they are right now. IMHO.\r\n\r\n5. I recently had to opportunity to visit a large supercomputer center. All the machines were roughly speaking speaking the size of a refrigerator (or several refrigerators, for the really big ones). Instead of exotic and super high speed designs (e.g., Cray), the machines all had thousands of processors each, where each of the thousands or processors were fairly mundane -- no faster than what most of us have on our desktops. The place reminded me of the old mainframe type computing centers where I used to work. The computer room floor was many thousands of square feet, and it was dominated by huge air conditioning units. Despite how mundane and low tech the chips are, when you put many thousands of them in one computer cabinet, they generate enormous amounts of heat. So the main function of this huge computer room was to supply huge amounts of cold air (and in some cases, cold water) to these new-fangled super computers. As I said earlier, the current fundamental problem with building powerful computers is dissapating all that heat.','68.47.230.99',1142971854,0,0,'3/','a:1:{i:0;i:0;}'),(217,0,29,23,'I\'m very optimistic that the','I\'m very optimistic that the search space for Rubik\'s cube can eventually be processed in it\'s entirety, but I think it\'s very unlikely that such a search can ever be processed \"one cube at a time\". \r\n\r\nPresent day \"one cube at a time\" solvers can take hours for solving one position. One the other hand, algorithms that enumerate cube space as a graph (often described as \"searching a tree\", except that formally it\'s a graph instead of a tree) already can process thousands of positions per second.\r\n\r\nFor example, my current solver which I used to calculate all positions up to 10f from Start and up to 13q from Start processes about 12,000 equivalence class representatives per second on the fastest machine on which I run it. My current equivalence class representatives take symmetry into account, but not anti-symmetry. So in effect, my solver processes about 500,000 positions per second, or about 2 micro-seconds per position. It\'s a far cry from that speed to a \"one at a time\" solver that can take hours per position.\r\n\r\nMy current solver was written over ten years ago, and was designed to minimize memory usage rather than to maximize speed. I\'m sure it could be speeded up a good bit by optimizing for speed, what with larger memory on modern machines, and the speed could be doubled for sure by taking anti-symmetry into account. And other solvers that have been described on this forum that operate in the mode of \"enumerating all of cube space\" seem to be at least as fast as mine, if not a good bit faster.\r\n\r\nBut let\'s just do a little arithmetic. In round numbers, the size of cube space is 4.3 x 1019. Reduced by symmetry and anti-symmetry, the size reduces to about 4.3 x 1017 (these are rounded off, \"back of the envelope\" type of calculations). Let\'s suppose we could someday produce 106 equivalence representatives per second on one machine (not unreasonable to suppose -- that\'s about 100 times faster than my current solver). The calculations would then take about 4.3 x 1011 seconds on one machine. There are about 3.1 x 107 seconds per year. So the calculation of cube space would take about 14000 years on one machine. If the problem were infinitely decomposable and amenable to running with all of its pieces in parallel, then 14000 machines could solve the problem in one year.\r\n\r\nAnother way to look at the problem is more like you did in supposing a certain amount of improvement every few years. I look at as that we can probably get one more level away from Start about every ten years. Looked at in that way, we about still about 100 years away from a solution.','68.47.230.99',1142977821,0,0,'4/','a:1:{i:0;i:0;}'),(218,217,29,39,'Coset approaches','I think the recent coset approaches (the edges coset I did and the new (U,D,F2,B2,R2,L2) approach that Silviu used) may yield something quite usable. For the edges coset, I see runs that take about a day for 44M positions with no symmetry; that\'s 500 positions a second, and most of these positions are at 18f. (This is M+inv representatives; if you want total positions, it is solving about 50,000 positions a second.) We are still working on the new approach, but it\'s quite possible it will be several orders of magnitude faster.\r\n\r\nThe nice thing about the coset approach is that you end up with a totally embarrassingly parallel solution---at least for the edges coset, each coset exploration is totally independent of each other and solves a completely disjoint set of positions.\r\n\r\nSo I do believe, if there is sufficient interest, we will have explored all of cube space in a relatively short time.\r\n\r\nOf course there are different questions. For instance, if the only thing we want to know is the diameter of the graph, then most coset explorations, which have their deepest positions at 19, will also eliminate all neighbor cosets (which can be no deeper than 20). This provides another factor of ten or more. If on the other hand we want an exact count of positions at each depth, then we\'d have to run each coset and this would be quite a bit more expensive.\r\n\r\nI suspect what will happen is either a 21f* will be found, somehow, at which point it will probably be accepted that that is the diameter, or else a reasonably significant fraction of the space will be explored with no 21*f found, and people will simply lose interest as the \"chance\" of there being a distance-21 position diminishes.\r\n\r\nBetween Kociemba\'s symmetry searches and Silviu\'s and my coset searches, we\'ve only found several hundred (almost 700) distance-20 positions altogether, and that\'s with many billions of \"candidate\" positions, ones that seem more likely to generate deep cubes. As Kociemba has stated, most antipodes of subgroups of the cube exhibit high symmetry; it seems unlikely that of all the distance 21 positions, none of them exhibit symmetry of four or greater. (Of course Kociemba is still finishing up some symmetry classes of symmetry 4, and I am still running edge cosets, so anything can happen.)\r\n\r\nOr, in a few years or so, when we end up with systems-on-a-chip with a gigabyte of memory and a good CPU, someone will probably put together a few thousand of these and just set them to work. No hard disk is needed, and very little network I/O (do this coset, do that coset).','64.160.186.130',1142988980,0,0,'4.1/','a:1:{i:0;i:0;}'),(219,218,29,34,'Very nice!!!\r\n\r\nThere is an i','Very nice!!!\r\n\r\nThere is an interesting improvement that one can do to this. You can explore each coset up to depth 18 and save all positions that are unfound i.e. the ones at depth 19 and up for that coset.\r\nAfter you explored every coset you collect the remaining positions in a set. Then you begin with the first position in the remaining set and multiply it by each generator if the result of this multiplication takes you out of the set then this position is at depth 19. If no multiplication takes you out of the set then its depth is higher then 19. \r\nIn this manner one can find all positions at depth 19. Afterwards continue with the same approach and find the depth 20 positions and so on. \r\nThe main disatvantage of the coset exploration is that when you come to higher depths you find to many solutions for the same position and this makes it impossible to run the coset until completion.\r\n\r\nThe improvement I mention is nothing else but a simple backwards search tehnique.','213.112.65.65',1143051056,0,0,'4.1.1/','a:1:{i:0;i:0;}'),(220,215,49,39,'Interestingly, even if you le','Interestingly, even if you leave the subgroup, in the face turn metric, there are still positions that require 18f*.','63.197.151.31',1143216069,0,0,'2.1.1/','a:1:{i:0;i:0;}'),(221,0,51,28,'I would like to do this too..','I would like to do this too....;-)\r\nHow many time did you need to compute the two tables? Did you solve some of the remaining positions individually?\r\nWould it be possible to compute cosets of one of the G/H 12-moves antipodes?','217.224.102.78',1143275188,0,0,'1/','a:1:{i:0;i:0;}'),(222,221,51,39,'The identity coset took 14 ho','The identity coset took 14 hours to complete. The flip8 coset took 32 hours to complete. In both cases, they ran to completion without any manual work (running of remaining positions or anything like that).\r\n\r\nIt would indeed be possible to compute the cosets of the antipodes. Right now the program has some simplifications that pertain only to the center positions, so I ran those first, but I plan to generalize the program to run any coset of H; this should be straightforward but I want to be cautious to make sure I don\'t goof up. For the center cosets, I had assistance from Silviu with his completely independent implementation so we could compare numbers and make sure they matched; I\'m hoping he\'ll help me for the non-center cosets too.\r\n\r\nThis coset is particularly nice for at least three reasons:\r\n\r\n1. The H group splits down into symmcoords beautifully and those symmcoords can be computed very fast; I\'m getting about 14M nodes a second on a P4. That\'s far faster than any other coset/pruning table I\'ve tried.\r\n\r\n2. Moves within H at the end of sequences can be computed separately from the main search since they stay within the group; that is, the main search need only consider sequences that end in a non-H move. This gives tremendous speedup.\r\n\r\n3. Moves that leave the symmcoords unchanged at the beginning of sequences can likewise be done separately from the main search; in the case of the center position, these are all moves in H.\r\n\r\nSo for the center position, the main search only considers sequences that both begin and end with moves not in H. This makes things a lot faster.\r\n\r\nFurther, to prove there are no 21s, you typically don\'t need to run a deep search; you can use what I call the prepass (a linear scan over the found positions, extending them by moves in H for (2) above, and by premoves for (3) above) repeatedly to find non-optimal solutions; I was able to prove the absence of any length-21 positions in less than an hour each for each of the four center cosets this way. Consider it nothing more than the Kociemba algorithm run in parallel; it\'s really little more than that.\r\n\r\nYour cube explorer program already contains almost all the code you need for this, just add code to index the cube by the permutations of the corners and edges, add a big bitvector, maybe some symmetry reductions of that bitvector, and you\'ve got essentially what I am running. Most of the implementation time for my program was spent reimplementing the H symmcoords (and your website was a great help with that); this is my first actual programming experience with this particular group.','63.197.151.31',1143300468,0,0,'1.1/','a:1:{i:0;i:0;}'),(223,0,51,39,'superflip coset finished','The superflip coset has finished; here is the distribution. The interesting thing is, despite my expectations, this coset has a lower average distance than the cube as a whole.\r\n\r\n\r\n10 2,560\r\n11 70,272\r\n12 1,120,128\r\n13 13,538,360\r\n14 133,692,540\r\n15 1,025,239,348\r\n16 4,847,352,684\r\n17 9,437,764,905\r\n18 4,030,528,357\r\n19 19,118,966\r\n20 680\r\n\r\n','63.197.151.31',1143391552,0,0,'2/','a:1:{i:0;i:0;}'),(224,223,51,28,'Very nice result. How many 20','Very nice result. How many 20f there are M+Inv-reduced? Did you store the maneuvers for the 20f during your run? I would be interested in them.\r\nIt also would be interesting to compute a random coset to see how close this distribution will be to the whole cube distribution.','217.224.105.99',1143404188,0,0,'2.1/','a:1:{i:0;i:0;}'),(225,224,51,39,'Unfortunately, because of my','Unfortunately, because of my optimizations in the search phase, this search did not include the solutions (although I do know the positions). I am currently trying to figure out how to recover the move sequences.\r\n\r\nSince I don\'t have any good notation for positions, the way I\'m dumping the positions is raw symmcoords, so there\'s no easy way to figure out the symmetry of the positions without writing more code. I\'m also working on this.\r\n\r\nAnd you\'re quite right; a random coset (or several!) would definitely be interesting. I suspect I\'ll start with the high-depth, high-symmetry cosets first, however; they run faster.','63.197.151.31',1143406249,0,0,'2.1.1/','a:1:{i:0;i:0;}'),(226,0,51,39,'The flip4 coset finally compl','The flip4 coset finally completed; here is its distribution.\r\n\r\nI\'m surprised at the low average depth. I hope I haven\'t made a mistake.\r\n\r\n
\r\n10 2,944\r\n11 78,656\r\n12 1,228,768\r\n13 14,644,176\r\n14 143,702,755\r\n15 1,106,407,845\r\n16 5,318,444,378\r\n17 9,940,797,145\r\n18 2,978,032,610\r\n19 5,089,463\r\n20 60\r\n','63.197.151.31',1143519657,0,0,'3/','a:1:{i:0;i:0;}'),(227,226,51,28,'The four cosets you computed','The four cosets you computed really do not seem to be representative for the distribution of a random coset. Because the fractional part of all 10-move maneuvers is 5.37*10^-9, there should be only about 105 10-move maneuvers on average in one coset. It is far more in all four cosets.\r\n\r\nI am quite sceptical if the computation for random coset will finish within a reasonable time.\r\nIf it takes a few days for each of the 4 cosets done, I estimate more than a month with a random coset where the average maneuver length is about 1 higher.','217.224.103.124',1143563931,0,0,'3.1/','a:1:{i:0;i:0;}'),(228,227,51,39,'Yeah, a random coset will def','Yeah, a random coset will definitely take quite some time to compute. It\'s still the fastest coset I\'ve seen, in terms of optimal solutions per second. And I still have a few ideas for making it yet faster. So all hope is not lost.','63.197.151.31',1143567353,0,0,'3.1.1/','a:1:{i:0;i:0;}'),(229,228,51,28,'I will try to compute another','I will try to compute another sort of cosets. With my very huge optimal solver I use a table which is 70 times larger than the usual pruning table with 64430*2187 entries to go to phase 2. The target group is 70 times smaller now, with \"only\" about 278 Mio elements.\r\n Because the average pruning depth is about one more compared with the standard pruning table it should be significantly faster and I hope that the computation for 70 cosets of this kind is faster than the computation of one coset of the 70 times larger group H. ','217.224.88.101',1143573589,0,0,'3.1.1.1/','a:1:{i:0;i:0;}'),(230,229,51,39,'It\'s definitely worth a try!\r','It\'s definitely worth a try!\r\n\r\nMy thoughts however are this. For a given coset, I believe you will end up exploring every possible solution up to the maximum length for every given position in that coset. That is, if position g is in your coset, and g has 15,391 solutions of length 20 or less, then no matter what pruning table you use, you will explore all 15,391 solutions when you explore that coset. (This is with a straightforward coset explorer that simply \"solves\" and then indexes into a bitvector.)\r\n\r\nIf this is true, then the only way to speed things up is to speed up your nodes per second, speed up your bitvector/indexing, or use some tricks to work around this duplication. Or try to explore cosets such that all deep positions are grouped together separately from the shallow positions, if that\'s possible.\r\n\r\nSo I don\'t think a deeper pruning depth actually helps here. I think the deeper pruning depth simply reflects the fact that you\'re solving fewer positions, nothing more than that.\r\n\r\nOn the other hand, there is this concept of reasonable computation time. For me, it\'s about 24 hours, and depending on how interested I am, perhaps up to a week (168 hours). Beyond that, I get distracted by other problems. So for this situation, certainly a smaller coset is preferable.\r\n','64.160.186.130',1143593593,0,0,'3.1.1.1.1/','a:1:{i:0;i:0;}'),(231,0,52,39,'Great work!\r\n\r\nOf the 771 kno','Great work!\r\n\r\nOf the 771 known depth-20 positions (known to me, that is, with contributions from both Kociemba and Silviu), 535 are\r\nantisymmetric but not self-inverse, and 142 are self-inverse,\r\nso a total of 677 of the 771 are antisymmetric.\r\n\r\nAre there more antisymmetric cubes than symmetric cubes? Maybe this would be an interesting set to study.','64.160.186.130',1143750439,0,0,'1/','a:1:{i:0;i:0;}'),(232,0,52,2,'First things first...','> Is there an explanation for the exceptional high number of antisymmetric cubes in the 20f* cases?\r\n\r\nCan we even explain clearly why the cubes of high symmetry should have a disproportionately large number of 20f cases?','130.88.128.98',1143826794,0,0,'2/','a:1:{i:0;i:0;}'),(233,232,52,39,'I can give you a stochastic a','I can give you a stochastic argument.\r\n\r\nLet\'s say the group is random, for some definition of a random group that I won\'t get into here. A position with low symmetry has more \"distinct\" moves to bring it closer to a solution; a position with high symmetry has fewer \"distinct\" moves.\r\n\r\nTake a center position, like superflip. In the quarter-turn metric, there is only a single move wrt M; in the half-turn metric, only two moves wrt M. A random assymetrical position, on the other hand, has 12/18 moves (QTM and HTM respectively), and thus has more \"chances\" to get closer to identity.\r\n\r\nAntisymmetry works in a similar fashion.\r\n\r\nAnother perspective is to consider the tree of positions reachable from the initial position, with respect to M+inv. From superflip and QTM, this tree has only a single position at depth 1, and (I think) five positions at depth 2; thus, a random position (say, identity) is more likely to be pretty deep in that tree. For an assymetrical position, the tree has 18 moves at depth 1, and a few hundred at depth 2, and so on; the tree is shallower and thus identity probably is closer.','64.160.186.130',1143829105,0,0,'2.1/','a:1:{i:0;i:0;}'),(234,233,52,2,'Thanks -- that\'s clearer. I','Thanks -- that\'s clearer. I can see now that others have alluded to arguments of this kind, without making them explicit.\r\n\r\n> Antisymmetry works in a similar fashion.\r\n\r\nExcept, perhaps, that the M+inv reduction is a little harder to visualize. It would be quite a subtle \"thinning out\" if you were starting from a self-inverse, unsymmetrical cube position.','130.88.128.98',1143835638,0,0,'2.1.1/','a:1:{i:0;i:0;}'),(235,234,52,39,'Wow, good point! I tend to o','Wow, good point! I tend to overlook this because frequently I think in terms of appending moves on both \"ends\" of a position (i.e., moves are not just position.U and position.F but also U.position and F.position) but you\'re quite right. I\'ll have to think some more about this.','64.160.186.130',1143840389,0,0,'2.1.1.1/','a:1:{i:0;i:0;}'),(236,227,51,39,'I\'ve been running some additi','I\'ve been running some additional cosets in \"Kociemba mode\"---that is, do the non-H search to a certain depth, and try to complete it with only H moves. With this approach I\'ve been able to complete an additional 63 (and still running) cosets, primarily those at distance 12, 11, and 10, and primarily those with some degree of symmetry. By complete, I mean I only verified that for these cosets there are no depth-21 positions. All told this represents more than 2E13 cube positions of the 4E19, so I\'ve explored approximately one two-millionth of cubespace (and by and large a deeper-than-representative portion because I start so deep in H) and not found a 21. If there is a 21, it\'s pretty elusive.','64.160.186.130',1143840851,0,0,'3.1.2/','a:1:{i:0;i:0;}'),(237,236,51,28,'Up to which depth you ran the','Up to which depth you ran the first phase?\r\nAnd what size has the bitvector you use?','217.224.102.157',1143893747,0,0,'3.1.2.1/','a:1:{i:0;i:0;}'),(238,237,51,39,'I ran the first phase at incr','I ran the first phase at increasing depths. I start most runs at depth 16 (but some I start at depth 15). If that doesn\'t find solutions for all positions in less than 20 moves, I try depth 17, and so on.\r\n\r\nSo far no coset has required me to explore a phase one beyond a depth 18. Most seem to succeed with a depth 17 search.\r\n\r\nI\'ve finished over 100 cosets now.','63.197.151.31',1143914238,0,0,'3.1.2.1.1/','a:1:{i:0;i:0;}'),(239,0,53,34,'Mark I tried to separate the','Mark I tried to separate the text from the tables but the enters where ignored of some reason. Could you please fix it for me?\r\n\r\n','213.112.65.91',1143927939,0,0,'1/','a:1:{i:0;i:0;}'),(240,239,53,1,'Is this better?','I added some <br> tags to separate paragraphs. There was a <pre> right at the beginning which I removed. \r\n
Thank you for that explanation, Jaap. By the way, I would also like to say that I \r\nfrequently look to your web site for information, and very much appreciate your web \r\nsite.
\r\nA few months ago, in a reply to Jaap\'s post about\r\nsolving the centers (centres) of the 4x4x4, Mark suggested attempting\r\nto extend Thistlethwaite\'s algorithm to the 4x4x4.I\'ve been looking at this, and have \r\ncome up with the following plan\r\nfor solving the 4x4x4 in five stages.\r\nThe squares coset analysis already given represents the fifth stage of this 5-stage \r\nprocedure. It is possible the following description might need some minor corrections. \r\nIf so, feel free to explain what you think needs to be corrected.
\r\nStage 1
\r\nOrient the corner cubies, and put the u- and d-layer edges into those two layers.\r\n(A d-layer edge may be in u layer, and a u-layer edge may be in the d layer.)
\r\nOne-time whole cube rotations: 120-degree turns (either direction) about the UFL-DBR \r\naxis.
\r\nSlice turns to use:
\r\nU,U\',U2,u,u\',u2,D,D\',D2,d,d\',d2,
\r\nL,L\',L2,l,l\',l2,R,R\',R2,r,r\',r2,
\r\nF,F\',F2,f,f\',f2,B,B\',B2,b,b\',b2
Stage 2
\r\nPut front and back centers onto the front and back faces into one of the twelve \r\nconfigurations that can be solved using only square moves. Arrange u- and d-layer edges \r\nwithin the u- and d-layers so that they will be in one of the 96 configurations that \r\ncan be solved using only square moves.
\r\nOne-time whole cube rotations: 90-degree turn about U-D axis.
\r\nSlice turns to use:
\r\nU,U\',U2,u,u\',u2,D,D\',D2,d,d\',d2,
\r\nL2,l2,R2,r2,
\r\nF2,f,f\',f2,B2,b,b\',b2
Stage 3
\r\nPut centers for left and right faces into the left and right faces so that they are in \r\none of the 12 configurations that can be solved using only square moves.\r\nPut centers for the U and D faces into the U and D faces.\r\nPut top and and bottom layer edges into positions such that the U or D facelet is \r\nfacing either up or down.
\r\nSlice turns to use:
\r\nU,U\',U2,u2,D,D\',D2,d2,
\r\nL2,l2,R2,r2,
\r\nF2,f,f\',f2,B2,b,b\',b2
Stage 4
\r\nPut corners into one of the 96 configurations that can be solved using only square \r\nmoves. Put U and D centers into one of the 12 configurations that can be solved using \r\nonly square moves. Put all U- and D-layer edges into a configuration that can be solved \r\nusing only square moves. This consists of 96 possible configurations for the l- and \r\nr-layer edges, and 96 for the f- and b-layer edges.
\r\nSlice turns to use:
\r\nU,U\',U2,u2,D,D\',D2,d2,
\r\nL2,l2,R2,r2,
\r\nF2,f2,B2,b2
Stage 5
\r\nPut all cubies into solved position.
\r\nOne-time whole cube rotations: 180-degree turns about U-D, F-B, L-R axes.
\r\nSlice turns to use:
\r\nU2,u2,D2,d2,
\r\nL2,l2,R2,r2,
\r\nF2,f2,B2,b2
I have already been working on stage 1. If anyone is interested in working on any of \r\nthe other stages, reply here. Otherwise, I will probably just continue on to stage 2, \r\nstage 3, and then stage 4 as I have time.
\r\n','70.22.161.85',1144552458,0,0,'1.1/','a:1:{i:0;i:0;}'),(247,246,54,31,'Stage 1 results','I have results for stage 1 of my plan for solving the 4x4x4 in five stages.\r\nThis stage starts with an arbitrary (legal) 4x4x4 position.\r\nThe goal of the stage is to orient the corner cubies\r\n(so the U or D facelet faces up or down)\r\nand to put the u- and d-layer edges somewhere in those two layers.\r\nThe center cubies are ignored in this stage.\r\nThere are 3^7 = 2187 possibilities for the orientation of the eight corner cubies.\r\nThere are 24!/(16!*8!) = 735471 combinations of placing a set of eight edge cubies\r\n(considered indistinguishable at this stage) among the 24 edge positions.\r\nSo this stage has a total of 2,187*735,471 = 1,608,475,077 positions.\r\nThe stage can be considered to include a one-time rotation of the whole cube (not counted as a move) so that the stage can be completed with what should be the \"up\" face facing a different direction. Because of symmetry, it appears to me only three orientations matter. So there are considered to be three solved states.
\r\n\r\nAs with the squares coset analysis, I have not only used the slice-turn metric, but also\r\nhave done analyses for \"twist turns\" and \"block turns\" as well.\r\nFor this stage, of course, I needed to consider quarter-turns as well as half-turns.\r\nI also change my definition for block turns to include moving a 4x4x3 block\r\nwith respect to the rest of the cube.\r\nSo the set of moves I used for each metric is listed below:
\r\n\r\nSlice turns:
\r\nU, U\', U2, u, u\', u2, D, D\', D2, d, d\', d2,
\r\nL, L\', L2, l, l\', l2, R, R\', R2, r, r\', r2,
\r\nF, F\', F2, f, f\', f2, B, B\', B2, b, b\', b2
Twist turns:
\r\nU, U\', U2, D, D\', D2, (U u), (U u)\', (U2 u2), (D d), (D d)\', (D2 d2),
\r\n(U u d\'), (U\' u\' d), (U2 u2 d2), (D d u\'), (D\' d\' u), (D2 d2 u2),
\r\nL, L\', L2, R, R\', R2, (L l), (L l)\', (L2 l2), (R r), (R r)\', (R2 r2),
\r\n(L l r\'), (L\' l\' r), (L2 l2 r2), (R r l\'), (R\' r\' l), (R2 r2 l2),
\r\nF, F\', F2, B, B\', B2, (F f), (F f)\', (F2 f2), (B b), (B b)\', (B2 b2),
\r\n(F f b\'), (F\' f\' b), (F2 f2 b2), (B b f\'), (B\' b\' f), (B2 b2 f2)
Block turns:
\r\nIncludes the union of the slice turns and twist turns, and also:
\r\n(u d\'), (u\' d), (u2 d2),
\r\n(l r\'), (l\' r), (l2 r2),
\r\n(f b\'), (f\' b), (f2 b2)
I did the analyses without using symmetry reductions, so I don\'t have\r\nsymmetry-reduced numbers available. At this point, I haven\'t done much\r\nto verify the results, so I am not yet totally confident in the results.
\r\n\r\n4x4x4 stage 1\r\n\r\ndistance slice turns twist turns block turns\r\n-------- ----------- ----------- -----------\r\n 0 3 3 3\r\n 1 6 6 6\r\n 2 156 228 336\r\n 3 3,560 8,463 13,806\r\n 4 70,636 286,922 519,157\r\n 5 1,237,252 7,739,249 15,833,805\r\n 6 18,075,027 140,009,317 275,936,444\r\n 7 178,452,186 850,633,007 1,029,284,931\r\n 8 715,636,485 602,898,722 286,686,684\r\n 9 639,448,150 6,899,160 199,905\r\n 10 55,545,380\r\n 11 6,236\r\n ------------- ------------ -------------\r\n 1,608,475,077 1,608,475,077 1,608,475,077\r\n\r\n','70.19.198.182',1144559369,0,0,'1.1.1/','a:1:{i:0;i:0;}'),(248,247,54,31,'Bad results for stage 1','Sorry, I have determined my results shown for stage 1 are in fact quite incorrect. The move table for corner orientation in my program was being generated incorrectly. I\'ll try to have corrected results in another day or two.\r\n','151.204.245.244',1144625500,0,0,'1.1.1.1/','a:1:{i:0;i:0;}'),(249,248,54,31,'stage 1 results','
I believe I now have correct results for stage 1 of my proposed 5-stage solution for the 4x4x4 cube. I have now also computed the number of positions that are unique with respect to the 16 symmetries of the cube that are relevant to this analysis.
\r\n\r\n\r\n4x4x4 Stage 1 analysis\r\n\r\n Slice turns\r\n ------------------------\r\ndistance positions unique\r\n 0 3 2\r\n 1 6 2\r\n 2 144 12\r\n 3 2,796 193\r\n 4 48,324 3,088\r\n 5 745,302 46,791\r\n 6 10,030,470 627,576\r\n 7 103,416,912 6,465,575\r\n 8 575,138,592 35,951,459\r\n 9 826,559,202 51,665,935\r\n 10 92,489,544 5,781,632\r\n 11 43,782 2,747\r\n ------------- -----------\r\n 1,608,475,077 100,545,012\r\n\r\n twist turns block turns\r\n ------------------------ ------------------------\r\ndistance positions unique positions unique\r\n 0 3 2 3 2\r\n 1 6 2 6 2\r\n 2 108 11 216 23\r\n 3 1,932 136 5,250 371\r\n 4 31,218 2,000 111,444 7,112\r\n 5 463,422 29,136 2,118,252 132,814\r\n 6 6,029,550 377,432 32,552,448 2,036,017\r\n 7 62,063,820 3,880,774 311,018,796 19,443,181\r\n 8 383,382,798 23,965,573 945,744,666 59,115,320\r\n 9 849,606,252 53,106,043 315,640,704 19,729,932\r\n 10 303,401,406 18,965,318 1,283,292 80,238\r\n 11 3,494,562 218,585 0 0\r\n ------------- ----------- ------------- -----------\r\n 1,608,475,077 100,545,012 1,608,475,077 100,545,012\r\n\r\n','70.19.199.92',1144732103,0,0,'1.1.1.1.1/','a:1:{i:0;i:0;}'),(250,249,54,31,'stage 1 using quarter-turns','
I\'ve now also done stage 1 analyses using only quarter turns.
\r\n\r\nFor clarity, the following lists define what I mean by the\r\nterms slice quarter-turns, twist quarter-turns, and block quarter-turns.\r\nI\'ve not included moves of 4x4x3 blocks here, since these are in effect redundant with face turns.
\r\n\r\nSlice quarter-turns:
\r\nU,U\',u,u\',D,D\',d,d\',
\r\nL,L\',l,l\',R,R\',r,r\',
\r\nF,F\',f,f\',B,B\',b,b\'
Twist quarter-turns:
\r\nU,U\',D,D\',(U u),(U u)\',(D d),(D d)\',
\r\nL,L\',R,R\',(L l),(L l)\',(R r),(R r)\',
\r\nF,F\',B,B\',(F f),(F f)\',(B b),(B b)\'
Block quarter-turns:
\r\nU,U\',u,u\',D,D\',d,d\',(U u),(U u)\',(D d),(D d)\',(u d\'),(u\' d),
\r\nL,L\',l,l\',R,R\',r,r\',(L l),(L l)\',(R r),(R r)\',(l r\'),(l\' r),
\r\nF,F\',f,f\',B,B\',b,b\',(F f),(F f)\',(B b),(B b)\',(f b\'),(f\' b)
\r\n\r\n slice quarter turns\r\n --------------------------\r\n\r\ndistance positions unique\r\n-------- --------- ------\r\n 0 3 2\r\n 1 6 2\r\n 2 96 6\r\n 3 1,416 98\r\n 4 16,872 1,069\r\n 5 189,324 11,900\r\n 6 1,979,916 123,914\r\n 7 18,083,490 1,130,772\r\n 8 124,919,346 7,809,155\r\n 9 496,644,282 31,044,284\r\n 10 735,316,956 45,962,786\r\n 11 225,406,314 14,090,907\r\n 12 5,916,864 370,105\r\n 13 192 12\r\n ------------- -----------\r\n 1,608,475,077 100,545,012\r\n\r\n twist quarter turns block quarter turns\r\n -------------------------- --------------------------\r\n\r\ndistance positions unique positions unique\r\n-------- --------- ------ --------- ------\r\n 0 3 2 3 2\r\n 1 6 2 6 2\r\n 2 72 5 144 11\r\n 3 1,044 72 2,952 197\r\n 4 11,076 702 47,268 3,007\r\n 5 114,300 7,196 686,970 43,050\r\n 6 1,174,608 73,559 8,774,946 548,899\r\n 7 10,639,320 665,492 84,204,966 5,264,307\r\n 8 75,344,742 4,710,401 444,840,750 27,806,624\r\n 9 339,690,198 21,233,782 794,156,340 49,640,245\r\n 10 703,609,584 43,980,444 268,019,748 16,754,428\r\n 11 432,863,106 27,057,913 7,739,808 484,162\r\n 12 44,831,274 2,803,112 1,176 78\r\n 13 195,744 12,330 0 0\r\n ------------- ----------- ------------- -----------\r\n 1,608,475,077 100,545,012 1,608,475,077 100,545,012\r\n\r\n','70.19.232.160',1144987772,0,0,'1.1.1.1.1.1/','a:1:{i:0;i:0;}'),(251,0,55,34,'Nice topic, seems that people','Nice topic, seems that people have forgotten about him altough his methods were maybe the beginning of computer puzzling(or am I wrong?). Do you know what he does nowdays?','213.112.65.15',1145444888,0,0,'1/','a:1:{i:0;i:0;}'),(252,251,55,4,'According to Morwen B. Thistl','According to Morwen B. Thistlethwaite\'s homepage, he is at the university of Tennessee.\r\n\r\nHis work was one of the first analyses of the Rubik\'s Cube, but I\'m sure he wasn\'t the only one doing it at that time. It was certainly the most successful and influential.\r\n\r\nUsing computers to analyse puzzles is much older than that. Solving the Towers of Hanoi or the Eight Queens Problem have been standard computer programming examples for recursion for years before that. I have no idea what the first puzzle is that was analysed with computer assistance.\r\n\r\n[Edit:\r\nOne of the very first puzzles analysed by computer is the pentomino puzzle on an 8x8 board with its centre 2x2 missing, done in 1958 by Dana Scott:\r\n\r\nDana S. Scott (1958). \"Programming a combinatorial puzzle\". Technical Report No. 1, Department of Electrical Engineering, Princeton University.\r\n]\r\n\r\nJaap\r\nJaap\'s Puzzle Page: http://www.geocities.com/jaapsch/puzzles/','134.146.0.12',1145446364,0,0,'1.1/','a:1:{i:0;i:0;}'),(253,252,55,23,'I have not met Morwen face to','I have not met Morwen face to face, but I have corresponded with him in the last year or so. (I live in Knoxville, which is also where Morwen lives. He\'s at the university. I worked there many years ago, but I presently work at Pellissippi State Technical Community College, also in Knoxville). Anyway, he reported that he really had not worked on Rubik\'s cube since his seminal work many years ago. I don\'t think he realizes how famous he is in the Rubik\'s Cube world.','198.146.200.47',1145538474,0,0,'1.1.1/','a:1:{i:0;i:0;}'),(254,0,56,39,'It\'s Silviu Radu; sorry I got','It\'s Silviu Radu; sorry I got the name backwards in the story. If anyone can fix the story, that would be excellent! Thanks!','63.197.151.31',1147102061,0,0,'1/','a:1:{i:0;i:0;}'),(255,0,56,39,'Due to some impossibly excell','Due to some impossibly excellent work by Silviu, the count of 20f*\'s is now up to 30,401. Still no 21f* in sight.','63.197.151.31',1147229180,0,0,'2/','a:1:{i:0;i:0;}'),(256,255,56,2,'That\'s a lot of 20f* position','That\'s a lot of 20f* positions. :)\r\n\r\nDo any of them lack symmetry? And how much of the searching has been done on positions (cosets?) without symmetry?','130.88.128.98',1147276902,0,0,'2.1/','a:1:{i:0;i:0;}'),(257,256,56,39,'Yep, out of the (still-increa','Yep, out of the (still-increasing) 30,403 (mod M+inv), there are currently 1,279 positions that are not symmetric mod M. Of these, 10 are self-inverses and 384 are antisymmetric but not self-inverse; the rest are not antisymmetric.\r\n\r\nMost of the cosets explored have exhibited symmetry, but a few have not. I have not run any positions totally lacking in symmetry with the big 19B solver yet because I still need to make one more modification in order to do that (I need to make it do the prepass to and from disk).\r\n\r\nI believe most 20f*\'s lack symmetry; the reason symmetrical positions are so common in our current list is because the majority of those positions were found by Silviu using a profound and amazing discovery I hope he will share soon.','64.160.186.168',1147292738,0,0,'2.1.1/','a:1:{i:0;i:0;}'),(258,256,56,28,'As you can see from Tom\'s fil','As you can see from Tom\'s file all20.txt, in the moment there are \"only\" 1279 20f* positions without symmetry. But this does not mean that there are less 20f* without symmetry than with some symmetry.\r\nThe percentage of positions with 20f* in the symmetric subgroups is much higher than in the cube group itself, so this was the main reason to take a closer look at the symmetric subgroups.\r\n\r\nWhile I was only able to find the 20f* in the smaller symmetric subgroups (the biggest was D2 (face) with about 300000 elements) Silviu Radu managed to completely analyze the really big symmetric subgroups like Ci etc. with billions of elements in a really beautiful way and I hope he is telling us more about his method here soon. Only two subgroups are left and I am sure we soon know that all symmetric positions of the cube can be solved within 20 moves.\r\n\r\nDoing this classification is the reason that we know much more symmetric 20f* positions in the moment than unsymmetric 20f* positions. \r\n\r\nBut it is not difficult to get many unsymmetric 20f* positions: Just take a symmetric 20f* position as the representant of a coset and do a coset search (the cosets I use have about 280 million elements and take about 4 hours to 2 days to compute depending on the symmetries). Typically a get in the order 10 to 100 new 20f* positions, though it also happens that the representant is the only 20f* position in the coset. Most of them have no symmetries. So I am sure that there are much more 20f* without symmetries than there are 20f* with symmetry.','84.167.199.193',1147294823,0,0,'2.1.2/','a:1:{i:0;i:0;}'),(259,250,54,31,'Stage 2 results (slice turns)','
I finally have results for stage 2 of my plan for solving the 4x4x4 in five stages.
\r\n\r\nThis stage starts with the corners oriented\r\n(so the U or D facelet faces up or down),\r\nthe u- and d-layer edges somewhere within those two layers,\r\nand the centers arbitrarily arranged.\r\nThe goal of this stage is to put the front and back centers\r\nonto the front and back faces into one of the\r\ntwelve configurations that can be solved using only half-turn moves,\r\nand to arrange the u- and d-layer edges within the u- and d-layers\r\nso that they will be in one of the 96 configurations\r\nthat can be solved using only half-turn moves.\r\nIn this stage, it is only necessary to consider the positions\r\nof the u- and d-layer edges,\r\nand the positions of the front and back centers.\r\nSince the u- and d-layer edges are constrained to the u and d layers,\r\nthere are 8! or 40320 possible arrangements of these edges.\r\nThe number of these positions that are considered solved as far as this stage\r\nis concerned is 96. The calculations for this stage were simplified\r\nby considering that the edges must be\r\nin one of 40320/96 = 420 equivalence classes.\r\nThe front and back centers can be in one of\r\n((24*23*22*21)/24)*((20*19*18*17)/24) = 51,482,970 arrangements.\r\nOf these, 12 are considered to be \"solved\" as far as this stage is concerned.\r\nI had hoped this would mean only 51,482,970/12 equivalence classes\r\nwould be needed, but this is not the case.\r\n(That isn\'t even an integer.)\r\nSo I considered all 51,482,970 center configurations in the analysis.\r\nThis makes the total positions for this stage 420*51,482,970 = 21,622,847,400.\r\nSince this is a rather large number, I used a sym-coordinate for the\r\nedge equivalence classes.\r\nWith 8 applicable symmetries, the 420 edge equivalence classes could be\r\nreduced to 98.\r\nThus, the analysis was done using a \"coordinate space\" of 98*51,482,970 = 5,045,331,060 elements.\r\nStage 2 allows one whole cube rotation of 90 degrees about the U-D axis,\r\nso the analysis uses 24 distance-0 positions rather than 12.\r\n(1 edge equivalance class, 12 center configurations, 2 cube orientations)
\r\n\r\nWith 1GB of RAM in my computer, I used only 1 bit per element in the main array, or\r\nabout 630 million bytes.\r\nI also used 98 disk files, with each file storing distances\r\nfor the set of 51482970 center configurations for a representative edge equivalence class.\r\nI used 4-bit distances to pack two distance values to a byte.\r\nSince the maximum distance turned out to be 18, this turned out to be insufficient,\r\nbut I was able to work around that problem.\r\n
\r\n\r\nThe disk files would be processed one at a time,\r\nlooking for positions of the previously determined distance,\r\nand then positions 1 move from those positions would be found.\r\nThe main array would keep track of these positions. After processing all 98 files,\r\nthe positions in the main array marked as being reached were checked against the files\r\nto see which ones were actually formerly at an unknown distance.\r\nA new set of 98 files updated for this new distance would be written during this process.
\r\n\r\nI\'ve only done the analysis for the slice turn metric for stage 2.\r\nThe slice turns used in this stage was restricted so that positions\r\nreached would remain within the set of goal state positions of stage 1.\r\nThese moves are:
\r\n\r\nU, U\', U2, u, u\', u2, D, D\', D2, d, d\', d2,\r\n4x4x4 Stage 2 analysis\r\n\r\n Slice turns\r\n ------------------------\r\ndistance positions unique\r\n-------- --------- ------\r\n 0 24 14\r\n 1 48 11\r\n 2 684 99\r\n 3 7,338 997\r\n 4 68,276 8,824\r\n 5 614,616 78,097\r\n 6 5,372,580 675,305\r\n 7 41,587,696 5,206,350\r\n 8 264,525,432 33,076,413\r\n 9 1,173,434,250 146,693,452\r\n 10 2,891,653,248 361,482,039\r\n 11 4,023,107,440 502,932,549\r\n 12 4,610,360,196 576,354,995\r\n 13 4,818,898,672 602,411,843\r\n 14 2,904,398,972 363,077,183\r\n 15 804,769,384 100,607,241\r\n 16 82,031,496 10,256,713\r\n 17 2,007,656 251,493\r\n 18 9,392 1,192\r\n ------------ -------------\r\n 21,622,847,400 2,703,114,810\r\n\r\n','70.22.181.84',1147544226,0,0,'1.1.1.1.1.1.1/','a:1:{i:0;i:0;}'),(260,0,57,44,'H={L, R, F2, B2, U2, D2} (correction of HTML-caused screwup)','use greater than sign, trouble comes your way.','69.123.66.114',1148090079,0,0,'1/','a:1:{i:0;i:0;}'),(261,0,57,34,'I think that Tomas Rokicki al','I think that Tomas Rokicki already tried a variant of this with his suboptimal solver. However testing each element of the group H for a given coset seem to take about an hour. So you have to multiply this with the number of cosets. For more details on his approach you can see the comments on his post about the group H.','213.112.65.15',1148141454,0,0,'2/','a:1:{i:0;i:0;}'),(262,0,57,44,'feasibility analysis','OK, I looked up some data on the www and\r\ndid some feasibility analysis of my plan to try to determine the maximin cube \r\nconfiguration and hopefully prove it is 20f (the superflip).\r\nLet us examine some data:\r\n\r\n
\r\nDik T. Winter (24 May 1992, corrected on May 28) \r\ncalculated the following exhaustive H coset in R\r\ndistance distribution:\r\n 0f 1\r\n 1f 4\r\n 2f 50\r\n 3f 592\r\n 4f 7156\r\n 5f 87236\r\n 6f 1043817\r\n 7f 12070278\r\n 8f 124946368\r\n 9f 821605960\r\n 10f 1199128738\r\n 11f 58202444\r\n 12f 476\r\ntot= 2,217,093,120\r\n\r\n\r\nOne apparent deficiency of this calculation was that it used only the 18 moves\r\n(U,D,R,L,F,B)^{1, -1, 2} at distance=1\r\nand did NOT use the 24 cube-body-rotation moves with distance=0.\r\nIf the latter had been used (which makes a difference because H\r\nis not symmetric under cube-body-rotations)\r\nthen quite probably distances would have decreased.\r\n
\r\nH = (U, D, F2, B2, R2, L2) enumeration by distance\r\nby Tomas Rokicki 2006 & Mike Reid 1995 (now indep\'yl confirmed)\r\n d all moves moves in H\r\n 0f 1 1\r\n 1f 10 10\r\n 2f 67 67\r\n 3f 456 456\r\n 4f 3,079 3,079\r\n 5f 20,076 19,948\r\n 6f 125,218 123,074\r\n 7f 756,092 736,850\r\n 8f 4,331,124 4,185,118\r\n 9f 23,639,531 22,630,733\r\n10f 122,749,840 116,767,872\r\n11f 582,017,108 552,538,680\r\n12f 2,278,215,506 2,176,344,160\r\n13f 5,790,841,966 5,627,785,188\r\n14f 7,240,785,011 7,172,925,794\r\n15f 3,319,565,322 3,608,731,814\r\n16f 145,107,245 224,058,996\r\n17f 271,112 1,575,608\r\n18f 36 1,352\r\n -------------- --------------\r\n 19,508,428,800 19,508,428,800\r\n\r\n\r\nOK, again, these authors apparently have not taken advanatge of 24-way cube-body-rotation\r\nsymmetry to get a 24-way reduction in storage space, although the table\'s first column\r\nof course does take advantage of that symmetry for the purpose of reducing the faceturn count\r\n(since the full group is invariant under the 24 cube-body-rotations even though H is not,\r\nH is only invariant under 4 rotations).\r\n
I now have results for stage 3 of my plan for solving the 4x4x4 in five stages.
\r\n\r\nThis stage starts with the corners oriented (so the U or D facelet faces up or \r\ndown), the u- and d-layer edges are in those layers in one of the \r\nconfigurations that can be solved using only half-turns, and the F and B \r\ncenters are in one of the twelve configurations that can be solved using only \r\nhalf-turns. The goal of this stage is to place the l-, r-, f-, and b-layer \r\nedges so that the top or bottom facelet is facing up or down, and to place the \r\nL and R centers into the left and right faces in one of the twelve \r\nconfigurations that can be solved using only half-turns. (This leaves the U and \r\nD centers to be arranged in some arbitrary manner within the top and bottom \r\nlayers. I note that each stage preserves what has been accomplished by the \r\nprevious stages.)
\r\n\r\nIn this stage, it is only necessary to consider what happens to the l-, r-, f-, \r\nand b-layer edges (which are also the top and bottom layer edges) and the \r\ncenters for the left and right faces (which may be located within the left, \r\nright, top, and bottom faces). The l-, r-, f-, and b-layer edges can be divided \r\ninto two sets of eight, depending on which locations they can occupy when their \r\nU or D facelet is \"oriented.\" Thus, as far as the edges for this stage are \r\nconcerned, it is only necessary to know the combination of positions occupied \r\nby one of the sets of eight cubies. Thus, there are a total of 16!/(8!*8!) = \r\n12,870 edge positions for this stage.
\r\n\r\nFor the centers, we only are concerned with where the left-face and right-face \r\ncenters are located, and they are known to be in the left, right, top, and \r\nbottom faces in this stage. So the number of center positions in this stage is \r\n(16!/(12!*4!))*(12!/(8!*4!)) = 900,900.
\r\n\r\nThus, the total number of positions in this stage is 12,870*900,900 = \r\n11,594,583,000. Symmetry can be used to reduce the total number of \"unique\" \r\npositions. It is possible to use eight of the 48 symmetries of the cube to \r\nreduce the number of edge positions from 12,870 to 1763. This reduces the \r\n11,594,583,000 positions to a \"coordinate space\" of 1763*900,900 = \r\n1,588,286,700 positions, of which 1,449,444,710 are unique with respect to the \r\nsymmetries used.
\r\n\r\nI used two bits per coordinate space position in memory, and created a disk file \r\ncontaining 4 bits per coordinate space position so that the disk file directly \r\ngives the distance for each of the 1,449,444,710 representatives.
\r\n\r\nAs with stage 2, I\'ve only done the analysis for stage 3 in the slice turn \r\nmetric. The slice turns used in this stage was restricted so that positions \r\nreached would remain within the set of goal state positions of stage 2. These \r\nmoves are:
\r\nU, U\', U2, u2, D, D\', D2, d2,
\r\nL2, l2, R2, r2,
\r\nF2, f, f\', f2, B2, b, b\', b2
\r\n
\r\n4x4x4 Stage 3 analysis\r\n\r\n Slice turns\r\n ------------------------\r\ndistance positions unique\r\n-------- --------- ------\r\n 0 12 7\r\n 1 24 6\r\n 2 300 47\r\n 3 3,112 427\r\n 4 32,620 4,241\r\n 5 338,192 42,764\r\n 6 3,422,856 429,378\r\n 7 33,301,210 4,167,562\r\n 8 296,684,804 37,101,001\r\n 9 2,069,017,694 258,660,323\r\n 10 6,422,550,196 802,864,880\r\n 11 2,752,074,608 344,028,608\r\n 12 17,157,252 2,145,448\r\n 13 120 18\r\n ------------ -------------\r\n 11,594,583,000 1,449,444,710\r\n\r\n','63.40.96.218',1150567426,0,0,'1.1.1.1.1.1.1.1/','a:1:{i:0;i:0;}'),(275,274,54,31,'Stage 3 Correction','
I have realized that I did Stage 3 incorrectly.\r\nThe problem is that I did not describe what stage 3 does correctly.\r\nI introduce a modified description for Stage 3,\r\nand provide the results for this corrected version of Stage 3.
\r\n\r\nIn looking at Stage 4, I noticed that the moves allowed in that stage\r\nall perform an even permutation on the edges.\r\nThus, if after completing stage 3, if the edges were in an odd permutation state,\r\nthey would have to remain in an odd permutation state in stage 4\r\n(as well as stage 5).\r\nSince the edge permutation of the solved cube is trivially an even permutation,\r\nit is apparent that Stage 3 must leave the edges in an even permutation.\r\nAs a result, it is necessary to add additional state information\r\nfor the analysis of Stage 3.\r\nThat information is whether the edges are in an even permutation\r\nor an odd permutation.\r\nIt is easy to incorporate this new information into the analysis.\r\nA separate boolean is added to track\r\nwhether the edge permutation is odd or even.\r\nThe moves f, f\', b, and b\' change the state of the boolean,\r\nwhile all other Stage 3 moves\r\n(U, U\', U2, u2, D, D\', D2, d2, L2, l2, R2, r2, F2, f2, B2, b2)\r\nleave the boolean unchanged.
\r\n\r\nThe main problem is that the number of total states doubles to 23,189,166,000.\r\nThe symmetry-reduced coordinate space I used doubles to 3,176,573,400 values,\r\nand the actual number of unique positions\r\nwith respect to applicable symmetries doubles to 2,898,889,420 positions.\r\nI decided to keep using two bits per position in memory,\r\nso the main array now consumed nearly 800 MB.\r\nSo it appears that my program needed to make use of virtual memory to some extent,\r\nbut the performance did not seem to be degraded too significantly.
\r\n\r\n\r\n4x4x4 Stage 3 analysis\r\n\r\n Slice turns\r\n ------------------------\r\ndistance positions unique\r\n-------- --------- ------\r\n 0 12 7\r\n 1 24 6\r\n 2 300 47\r\n 3 3,112 427\r\n 4 32,620 4,241\r\n 5 338,480 42,806\r\n 6 3,434,920 430,920\r\n 7 33,776,210 4,227,153\r\n 8 311,683,476 38,977,409\r\n 9 2,439,504,410 304,981,049\r\n 10 10,729,223,804 1,341,243,036\r\n 11 9,375,305,144 1,171,989,581\r\n 12 295,853,444 36,991,377\r\n 13 10,042 1,360\r\n 14 2 1\r\n -------------- -------------\r\n 23,189,166,000 2,898,889,420\r\n\r\n','63.40.66.120',1150838383,0,0,'1.1.1.1.1.1.1.1.1/','a:1:{i:0;i:0;}'),(276,0,61,31,'Probably more than three phases will be needed','
The standard 4x4x4 cube has about 7.4e+45 positions,\r\nwhile the standard 5x5x5 cube has 2.8e+74 positions.\r\n(I looked these up on \"Jaap\'s Puzzle Page\" web site.)\r\nThese numbers seem to indicate your initial phase will require\r\nsearch spaces of around 2e+26 and 6e+54 positions.\r\nAs these numbers are much higher than the order of the 3x3x3 cube group,\r\nfor which Kociemba uses two phases, I believe you will need to prepend\r\nmore than a single phase for these bigger cubes.\r\nI am guessing you might be able to do the 4x4x4 with two added phases, perhaps one for the \r\n\r\ncenters, and one for pairing the edges.\r\n(In pairing edges, you probably also want to avoid the parity situations,\r\nbut I won\'t get into that detail here.)\r\nI am guessing three or four added phases may be required for the 5x5x5.
\r\n\r\nIf you try to use too few phases, the number of moves to do each phase\r\nmay become too large to get a solution for a given phase in a reasonable time.\r\nTo get good quality (reasonably close to optimal) solutions in a reasonable time,\r\nI believe you want to use as few phases as possible,\r\nwithout any given phase needing excessive execution time.\r\nYou didn\'t say what kind of execution time or quality of solution (closeness to optimal) you hoped to achieve.\r\nI believe it will take a lot of experimenting to find the right compromise between finding a solution quickly enough and a solution that\'s as close to optimal as you would like.
\r\n\r\nNote that on this forum, Jaap Scherphuis has an article\r\n\"The 4x4x4 centres can be solved in 22 moves\" in which he talks about\r\na two-phase solution for the centers (or centres).\r\nWhile Jaap used two phases, I assume the centers can be solved in a single phase\r\nwith an IDA* type of algorithm,\r\npossibly using Jaap\'s phase 1 table as a pruning table (although I think there may be \r\n\r\nbetter choices for a pruning table).\r\n
\r\n\r\nPairing the edges after solving the centers requires\r\ntemporarily disturbing the solved centers.\r\nThis would seem to add some complications to the search algorithm,\r\nbut I believe that can be handled.\r\nThere may be other ways to split up the problem of going from\r\nscrambled 4x4x4 to scrambled 3x3x3 that may avoid this,\r\nand perhaps get better solutions as well.
\r\n\r\nKociemba considers sub-optimal solutions for the first of his two phases.\r\nLet\'s say you add two phases for the 4x4x4.\r\nIf you also consider sub-optimal solutions in those two phases, I believe the run-time \r\n\r\ncould increase dramatically over what it would take if\r\nonly one optimal solution to each phase is considered.\r\nIf you want solutions generated quickly, I think the number of solutions\r\nconsidered in the earlier phases may have to be kept fairly small.
\r\n\r\nI will also note that I am working on a five-stage algorithm of solving the 4x4x4.\r\nSee my post \"God\'s algorithm calculations for the 4x4x4 \'squares set\'\" on this forum\r\nand my follow-up posts to that post.\r\nIt looks like my five-stage algorithm will guarantee a solution of any 4x4x4\r\nposition in no more than about 80 slice turns.
\r\n','70.19.198.212',1151707120,0,0,'1/','a:1:{i:0;i:0;}'),(277,275,54,31,'Stage 4 analysis run','I have run an analysis for Stage 4 of my five 5-stage analysis.\r\nWhile I plan to do some additional validation checking of the results\r\nbefore giving details,\r\nthe analysis indicated it takes 16 slice turns (maximum) to do this stage.
\r\n\r\nAssuming the correctness of this and the earlier results, this 5-stage analysis indicates that the 4x4x4 cube can be solved for any legally scrambled configuration\r\nin no more than 78 slice turns! (11 + 18 + 14 + 16 + 19 = 78)
\r\n\r\nI have tried doing internet searches for any information\r\non an upper bound for the number of moves to solve the 4x4x4,\r\nbut haven\'t been able to find any mention of other upper bound values.\r\nIf anyone knows of any, I would like to know.\r\nBut I am guessing that no upper bound lower than this value has\r\nbeen determined to this date.
','70.19.198.212',1151902303,0,0,'1.1.1.1.1.1.1.1.1.1/','a:1:{i:0;i:0;}'),(278,277,54,34,'Congratulations Bruce! \r\n\r\nI','Congratulations Bruce! \r\n\r\nI think this is the first upper bound on the 4x4x4 cube. I am surprised of how low this number is (no particular reason why). \r\n\r\nBtw, do you know any lower bounds for the 4x4x4?\r\n\r\nSilviu\r\n','213.112.65.45',1151910263,0,0,'1.1.1.1.1.1.1.1.1.1.1/','a:1:{i:0;i:0;}'),(279,278,54,31,'some former 4x4x4 bounds','Well, certainly 7,401,196,841,564,901,869,874,093,974,498,574,335,999,999,999 was known to be an upper bound. But my value of 78 may be the first \"reasonably close\" upper bound to be claimed.
\r\n\r\nI might mention that Stage 3 in my analysis has just two antipodes (and they are symmetrically equivalent), so this might allow reducing the upper bound to 77.
\r\n\r\nIn the old \"cube-lovers\" archives, Dan Hoey had calculated lower bounds of 41 quarter-turn twist moves, and 37 quarter turns of slices (\"slabs\" in his terminology). He also gave 48 as a lower bound for the 4x4x4 supercube in quarter-turn twist moves. Hoey used counting arguments to arrive at his numbers. I am assuming that we don\'t have any \"known\" positions of that depth.
\r\n\r\nIn a quick search, I did not find any lower bounds for any half-turn metrics.
\r\n','70.19.198.212',1151949566,0,0,'1.1.1.1.1.1.1.1.1.1.1.1/','a:1:{i:0;i:0;}'),(280,277,54,31,'Oops, make that 79 instead','In doing my validation work for my 5-stage analysis, I found that I made a mistake in the handling of the corner configurations in my stage 4 analysis. It now looks to me that my stage 4 requires 17 slice turns maximum, not 16. So with this correction, the total number of slice turns possibly required is now 79.
\r\n\r\nOn the positive side, I have been creating a solver program that will take a 4x4x4 position, and directly solve it using the results of the 5-stage analysis. I have used it to take a test case through the first four stages, and it generated a correct move sequence to transform the initial position into a squares coset position. So now I need to add stage 5 to my solver, and try a lot more test cases.
\r\n\r\nIt looked to me that there might be a problem with my stage 5 results, so I\'ve concentrated on testing the first four stages, and now will look at the fifth stage. It is currently my belief that 19 is still the maximum number of slice turns needed for stage 5.
\r\n','70.19.240.204',1152323155,0,0,'1.1.1.1.1.1.1.1.1.1.2/','a:1:{i:0;i:0;}'),(281,0,62,31,'Stage 4 details and symmetry-reduced results','I had calculated symmetry-reduced numbers for each of the 5 stages in my analysis, except the \r\n\r\nfourth stage. So I have now calculated symmetry-reduced values for Stage 4. Since this stage had a \r\n\r\n\"mere\" 2,593,080,000 positions, I did my initial analysis of it without going to the trouble of using \r\n\r\nsymmetry to reduce the number of positions. Since 16 of the 48 elements of the symmetry group of the \r\n\r\ncube are applicable to Stage 4, the total number of positions can be reduced almost 16x using \r\n\r\nsymmetry.\r\nThe results are given below. Following that, I discuss Stage 4 in more detail.
\r\n\r\n\r\nStage 4\r\n\r\n Slice turns\r\n ------------------------\r\ndistance positions unique\r\n-------- --------- ------\r\n 0 12 5\r\n 1 24 4\r\n 2 204 19\r\n 3 1,280 97\r\n 4 7,548 527\r\n 5 40,964 2,783\r\n 6 227,816 14,852\r\n 7 1,259,844 80,308\r\n 8 6,912,088 436,088\r\n 9 35,259,020 2,214,786\r\n 10 152,072,296 9,531,856\r\n 11 466,530,500 29,208,755\r\n 12 759,591,796 47,546,251\r\n 13 738,648,672 46,237,953\r\n 14 387,337,472 24,256,088\r\n 15 45,079,256 2,833,318\r\n 16 111,144 7,430\r\n 17 64 12\r\n ------------- -----------\r\n 2,593,080,000 162,371,132\r\n\r\n
While Stage 4 had only a \"small\" number of positions, I had some difficulty defining\r\nprecisely what those positions are.\r\nIt was the edge cubies that I had a difficult time with. For Stage 4, the sixteen edge \r\ncubies in the top and bottom layers of the cube are the edge cubies that matter.\r\nIn Stage 3, they are separated out into eight \"left-handed\" cubies and eight \"right-handed\" cubies.\r\nSo there are 8! possible positions of the left-handed cubies and 8! possible positions of the right-handed cubies.\r\nSince the cubies must be in an even permutation, only half the positions are allowed, so there are a \r\ntotal of (8!2)/2 or 812,851,200 possible permutations of these sixteen edge cubies.\r\nIn Stage 4, we need to put these cubies into a configuration\r\nthat can be solved with only half-turns. \r\nThere are 962 or 9,216 such configurations.\r\nTherefore, for Stage 4, we should be able to define the edge\r\npositions as cosets each containing 9,216 permutations.\r\nSo the number of edge positions needed for Stage 4 is\r\n812,851,200/9,216 or 88,200.
\r\n\r\nI then proceeded to figure out a way to efficiently convert each of the 812,851,200\r\nallowable permutations of the edge cubies to the proper one\r\nof 88,200 representative positions.\r\nI then built a hash table to store the 88,200 representatives,\r\nalong with an index number, so I could efficiently convert a\r\nrepresentative into a number from 0 to 88,199.\r\nThen I could use these two steps to somewhat efficiently convert any of the 812,851,200 permutation values into a \"coordinate\" value from 0 to 88,199.\r\nPerhaps there is a more elegant way this could be done,\r\nbut this at least well enough to get the analysis done.
\r\n\r\nThe corners had 8! possible permutations, and needed to be put into one of 96 configurations\r\nthat can be solved using only half-turns.\r\nThus, there were 8!/96 or 420 cosets for the corner positions.\r\nA table used for Stage 2 edges could be used to map the 40,320 permutations to one of the 420 Stage 4 corner positions.
\r\n\r\nThere are 8!/(4!2) or 70 possible configurations for the top\r\nand bottom centers within those two faces.\r\nWhile there are 12 configurations that are considered solved as far as Stage 4 is concerned,\r\nsince the centers don\'t form a group,\r\nI simply treated the centers as having 70 possible positions.\r\nThis results in a total of 88,200 * 420 * 70 or 2,593,080,000 positions for Stage 4.
\r\n\r\nFor more information on the analyses of the other stages, see my post\r\nentitled \'God\'s algorithm calculations for the 4x4x4 \"squares set\"\' and its follow-up posts.
\r\n','70.19.198.10',1153363008,0,0,'1/','a:1:{i:0;i:0;}'),(282,279,54,53,'4x4x4 lower bound','At most 36^29 + 36^28 + 36^27 + ... (approx. 1/6 of the number of positions of a 4x4) positions can be reached in 29 slice turns or less, so there are positions that require at least 30 slice turns.','66.136.146.35',1154204310,0,0,'1.1.1.1.1.1.1.1.1.1.1.1.1/','a:1:{i:0;i:0;}'),(283,0,64,53,'No offense, but you honestly','No offense, but you honestly sound like a professional advertiser.','66.136.146.35',1154204458,0,0,'1/','a:1:{i:0;i:0;}'),(284,283,64,56,'That\'s a good thing though, R','That\'s a good thing though, Ravi. Any how I have just spent the last hour trying all the different ways to do this and find all the typos in the solution. For certain there is at least one typo there, because I perform it as is and it does not work.\r\n\r\nOne of the more dubious lines:\r\nRB [M\'UM\'UMU2MUMUMU2] B\'R\'\r\nshould probably be more like:\r\nRB [M\'UM\'UM\'U2MUMUMU2] B\'R\'\r\nthe first lone M should be an M\' I suspect.\r\n\r\nAlso I don\'t know what you meant by \"S2, y, x\", because that could be dipping into \"conjugation notaiton\" or \"commutation notation\". Pauses are usually denoted by either a \'.\' or \'-\'. These pauses are used interchangable although technically, I would use a \'.\' for a non-obvious pause between phases (esp computer program phases) and a \'-\' for a more obvious stop between steps or a merging of two irreducible sequences as well as doing things like \"(F\'-F)\".\r\n\r\nI know almost all of those algs, or at least the case that the alg solves for, so this wouldn\'t be too hard for me to learn if more details where released. Pretty interesting for sure.\r\n\r\nCould you please go through and double check the solution and validate it so that ppl don\'t start gettign angery at you.\r\n\r\n\r\n-Doug\r\n\r\np.s. this is my first post here, I am the same Doug that went to Nationals06 and moderates the yahoo forum','68.42.73.11',1156153403,0,0,'1.1/','a:1:{i:0;i:0;}'),(285,0,11,59,'anyone!!!','I have a problem cube and if anyone can help me that would be great.\r\n\r\nI have 6 blocks size 3x2x2cm \r\n 6 blocks size 4x1x1cm\r\n 5 blocks size 1x1x1cm\r\n\r\nI need them to fit perfectly into a cube size 5x5x5cm\r\n\r\nCan anyone think of a way to do it?????','80.3.32.5',1159210267,0,0,'1/','a:1:{i:0;i:0;}'),(286,285,11,34,'A friend of mine Camelia Rose','A friend of mine Camelia Rosenkranz solved this problem for fun.\r\nYou can see this visually by starting the following Mathematica file:\r\nhttp://users.student.lth.se/f01sr/ACube.nb\r\n\r\nSilviu','193.170.37.118',1159534409,0,0,'1.1/','a:1:{i:0;i:0;}'),(287,0,63,28,'Some more information','Maybe a good summary for the analysis of the symmetric cubes in FTM is the following table, which gives the number of cubes, which have some symmetry as a function of the maneuver length.| Distance | \r\n Number | \r\n Distance | \r\n Number | \r\n
0f | \r\n 1 | \r\n 11f | \r\n 9,732,164 | \r\n
1f | \r\n 18 | \r\n 12f | \r\n 35,024,904 | \r\n
2f | \r\n 51 | \r\n 13f | \r\n 122,054,340 | \r\n
3f | \r\n 312 | \r\n 14f | \r\n 436,197,214 | \r\n
4f | \r\n 1,335 | \r\n 15f | \r\n 1,763,452,505 | \r\n
5f | \r\n 4,380 | \r\n 16f | \r\n 8,035,307,127 | \r\n
6f | \r\n 17,782 | \r\n 17f | \r\n 37,542,012,922 | \r\n
7f | \r\n 70,188 | \r\n 18f | \r\n 95,387,902,305 | \r\n
8f | \r\n 229,336 | \r\n 19f | \r\n 21,267,102,443 | \r\n
9f | \r\n 851,139 | \r\n 20f | \r\n 1,091,994 | \r\n
10f | \r\n 2,989,204 | \r\n 21f | \r\n 0 | \r\n
\r\nD2 F2 L2 D\' U L2 F2 D\' U\' (9f*) \r\nU2 B2 L2 D U\' R2 B2 D\' U\' (9f*) \r\n\r\n\r\nThe positions look extremely symmetric, but the first one only has two symmetries and the second one only has six symmetries.\r\n\r\nFor the first position, the two symmtries are the identity and the central inversion.\r\n\r\nFor the second position, the six symmetries are the identity, a 120 degree rotation about a major diagonal axis, a 240 degree rotation about the same major diagonal axis, and the central inversion composed with each of the three rotations.\r\n\r\nThe two positions look almost identical, and differ in subtle ways. They both have the following property. Consider a cube that is colored according to the \"opposite faces differ by yellow\" convention. Namely, white is opposite yellow, blue is opposite green, and red is opposite orange. Call the white and yellow faces \"whitish\". Call the blue and green faces \"bluish\". Call the red and orange faces \"redish\". Then, both of these positions have the property that they preserve the whitishness of the whitesh faces, they preserve the bluishness of the bluish faces, and they preserve the redishness of the redish faces.','71.203.230.238',1166851055,0,0,'1/','a:1:{i:0;i:0;}'),(291,290,69,28,'Preservation of bluishness etc.','The two positions are in (U2,D2,R2,L2,F2,B2), where all positions have this property.\r\n\r\nL2 U2 B2 D2 R2 D2 R2 B2 L2 U2 (10f)\r\nL2 D2 F2 U2 R2 D2 L2 F2 R2 U2 (10f)\r\n\r\nI did not look if these positions also are strong local maxima in this subgroup.','84.167.78.40',1166882747,0,0,'1.1/','a:1:{i:0;i:0;}'),(292,0,70,1,'Edited title','Hi there, please avoid long titles like that. Limit it to 20 characters or less. Thanks :)\r\n\r\nIf you click on the lemniscate on the right you can see many similar calculations including the 2x2x2 one you posted. I think you are saying that the number of odd positions is equal to the number of even positions. Yes it\'s been noted before.\r\n\r\n\r\n\r\n','204.225.123.154',1168478860,0,0,'1/','a:1:{i:0;i:0;}'),(293,0,70,23,'Even and Odd Permutations','There\'s a basic theorem in group theory that says that for a finite permutation group, either all the permutations are even, or else half the permutations are even and half are odd. Most of the cube groups that people are interested in consist of permutations where half of the permutations are even and half of them are odd. The most common cube group is the complete group of the 3x3x3 cube, and it certainly has the aforementioned characteristic that half the permutations are even and half the permutations are odd.\r\n\r\nThe half even/half odd theorem depends on an even more important theorem that says that any given permutation is either odd or even but not both. That is not a trivial theorem. Any permutation can be decomposed into transpostions, where a transposition is a 2-cycle. As an old programmer from way back, I would simply call these things \"swaps\". However, the decomposition of a permutation into transpositions is not unique. Therefore, it is not immediately obvious that every single possible decomposition must have the same parity, and it\'s a difficult thing to prove. The theorem asserts that no matter which decomposition is chosen, the parity will always be the same.\r\n\r\nWhen two permutations are composed, the parity rules are the familiar and obvious ones. The composition of two even permutations is even. The composition of two odd permutations is even. The composition of an even and an odd permutation is odd. And the composition of an odd and an even permutation is odd.\r\n\r\nIn the quarter turn metric, the parity of the permutations is the same as the parity of their respective distances from Start. That\'s because a quarter turn itself is odd. Therefore, an even permutation is an even number of moves from Start, and an odd permutation is an odd number of permutations from Start. Hence, half of all positions are an even number of moves from Start and half of all positions are an odd number from Start.\r\n\r\nIn the face turn metric, the parity of the permutations need not be the same as the parity of their respective distances from Start. As a trivial example, there are 18 positions that are one move from Start. 12 of these positions are odd (a quarter turn\'s worth), and 6 of these positions are even (a half turn\'s worth). Therefore, it need not be the case that half the positions are an even number of moves from Start and half the positions are an odd number of moves from Start in the fact turn metric.','198.146.200.77',1168526928,0,0,'2/','a:1:{i:0;i:0;}'),(294,293,70,70,'Thanks Jerry for your explana','Thanks Jerry for your explanation.','192.104.61.176',1168532421,0,0,'2.1/','a:1:{i:0;i:0;}'),(295,0,72,31,'Re: Lower bound using the Edges antipode','Mike Reid\'s web site gives a position (he calls it \"Superfliptwist composed with Pons Asinorum\") that is 22q* and is in the edges antipode equivalence class. Therefore, X >= 22. See: http://www.math.ucf.edu/~reid/Rubik/h_symmetric.html\r\n\r\nWhen I have some spare time, I might try to look at generating the 2-D QTM distribution table for the edges group for distance from solved vs. distance from antipode.\r\n\r\n - Bruce Norskog','70.22.138.126',1170213844,0,0,'1/','a:1:{i:0;i:0;}'),(296,295,72,70,'Hi Bruce,','Hi Bruce,\r\n\r\nThank you for your reply.\r\n\r\nLet me know if I can help generating this 2D QTM distribution. I do have time and computer resources unfortunatly I am lacking a good code that will not take ages to produce this full distribution.\r\n\r\nIf we prove that X is equal to 22 (I am working on this using Mike\'s optimal solver) and if turns out that Y is less than 13 then a new lower bound can be reached hopefully.\r\n\r\nThanks\r\n\r\n','192.104.61.176',1170265214,0,0,'1.1/','a:1:{i:0;i:0;}'),(297,295,72,70,'X IS equal to 22','I just found out that Tom has already proved that X=22 here:\r\nhttp://cubezzz.homelinux.org/drupal/?q=node/view/44\r\n\r\nIt is the fourth calculation.\r\n\r\nThis means that each cube position can either choose to go to the edges identity or to the edges antipode then add 22 to go to the cube identity.\r\n\r\nEach cube position has to find out which is the closest to it, the edges identity or the edges antipode. That way we avoid adding 18 but only add a number Y between 9 and 17.\r\n\r\nThis gives an upper bound of 39 but I hope that Y is less than 13 to break the 35q limit...','192.104.61.176',1170453491,0,0,'1.2/','a:1:{i:0;i:0;}'),(298,297,72,31,'Y >= 14','I have done a test run of a preliminary version of my program for generating the two-dimensional table for the edges group, giving distance from solved vs. distance from the antipode. This program only looked at even permutation positions, and obtained results for about 730,000 positions (unique with respect to M-symmetry). Assuming it was working correctly, it found many positions that are at least distance 14 from both the solved position and the antipode. In fact it was a little over 32% of the positions.\r\n\r\nThis should not be surprising. If you look at the distance table for the edges group (QTM), you see that about 56.6% of the even permutation positions are depth 14. Since that is a majority of even permutation positions, at least some of them must also be a distance of 14 from the antipode. You could estimate that 56.6% of the distance-14 positions would also be a distance of 14 from the antipode. In fact, 56.6% of 56.6% is about 32%, in close agreement with my sample.\r\n\r\nFor odd permutation positions, over 90% are depth 13. Therefore, it would be expected that about 81% of the positions are a distance of 13 from both the solved position and the antipode.\r\n\r\nTo get a smaller upper bound for Rubik\'s cube in QTM, it was hoped that every position of the edges group would be within 12 quarter turns from either the solved position or the antipode. However, it is clear to me that there are a very large number of positions for which this is not the case.\r\n\r\n - Bruce Norskog','70.19.235.69',1170654629,0,0,'1.2.1/','a:1:{i:0;i:0;}'),(299,298,72,70,'Hi Bruce,','Hi Bruce,\r\n\r\nThank you for your calculation.\r\n\r\nWell, I am disapointed at the result but all hope is not lost after reading this from Jerry Brayn and the reply from Dan Hoey here:\r\nhttp://www.math.rwth-aachen.de/~Martin.Schoenert/Cube-Lovers/Jerry_Bryan__Some_Additional_Distances_in_the_Edge_Group.html\r\n\r\nIt gave me the idea of looking for a 4D distribution instead of the 2D distribution you calculated. The 4D distribution would be the distance from the identity (I), the pons asinorum (P), the superflip (E) and the pons asinorum+superflip (PE). So that each cube position would have a choice of 4 routes whichever is closest to it...\r\n\r\nThe cosets corresponding to this 4 positions have all been calculated by Tom Rokiki here:\r\nhttp://cubezzz.homelinux.org/drupal/?q=node/view/44\r\n\r\nand they can all be solved in 22 moves except 5 positions [up to symmetry] in the superflip coset which need 24 moves. However those 5 positions might be searched exhaustively to prove that they can be avoided all the time.\r\n\r\nWith 4 routes to choose from for each cube position we might have a better chance to have a distance < 13.\r\n\r\nThinking however about your argument about the 90% at depth 13 and how that would make you expect about 81% at distance of 13 from both the solved edges and the antipode edges, I came to realize that even with 4 routes to choose from I would still expect 65% to be at distance of 13 from all of the 4 starting points...\r\n\r\nIf 4 routes are not enough then let\'s add more. The H-symmetric positions at Mike\'s website http://www.math.ucf.edu/~reid/Rubik/h_symmetric.html seem to be good condidates for such an attempt.\r\n\r\nSo instead of 4 routes I would have 24 routes to choose from... If this does not lower Y to under 13 I do not know what else does!;) \r\n\r\nOne thing is sure is that the more \"independent\" [Do not ask me what I mean by independent because I do not know] routes we add, the more better chance we have of lowering Y...\r\n\r\n\r\nTo conduct such a culculation, I need to create 20 [actually only 8 thanks to symmetry] more tables, similar to what Tom Rokiki did for the 4 points [I,E,P,EP]. If Tom Rokiki is reading this, I would be very grateful if you can share your code with which you did the 44millions calculation. \r\n\r\nI would also need to produce a 24D distribution similar to what you did for the 2D distribution. If you can share with me your code I will also be very garteful.\r\n\r\nJerry Brayn says here \r\nhttp://www.math.rwth-aachen.de/~Martin.Schoenert/Cube-Lovers/Jerry_Bryan__Some_Additional_Distances_in_the_Edge_Group.html\r\n\r\nthat if you already know the 1D distribution from Start then you can find the distance of any position to a different position that has some symmetry relation to Start thanks to conjugacy... I did not fully understand his argument but it sounds like the 24D distribution I am looking for can be deducted from the 1D distribution somehow...\r\n\r\nThanks a lot!','192.104.61.176',1170725605,0,0,'1.2.1.1/','a:1:{i:0;i:0;}'),(300,299,72,31,'about my calculation','I was using that idea to calculate my distance table.\r\n\r\nLet x be a position in the edge group. Let Z be the antipode. Then x\'*Z takes x to the antipode Z. So you just look up the position x\'*Z in the edge group distance table to get the distance from x to Z.\r\n\r\nI generated the distance table for the edge group in December 2005, to provide independent verification of Rokicki\'s result. I used that data to do my calculation. Since my data table is over to 18GB (with 1GB defined as 1000^3 bytes), I only loaded a small portion of it into memory. My data consists of 76 files for even permutations and 76 files for odd permutations. So I loaded 6 of the even permutation files into memory. Then I looked for positions from a subset of this space for which x\'*Z was also in the space. This avoided the need to perform a random-access disk file lookup to get the distance of x\'*Z. By limiting the amount of positions it tried, it only took a few minutes to run and get results for over 700,000 positions.\r\n\r\nI figured this idea could be extended to generate the whole 2-dimensional table. This would not extend well to looking up distances to a set of 24 positions, since it is very unlikely to have all 24 computed positions to be within the subset of the table loaded into memory. Perhaps performing random access disk file lookup would be what you would have to do, but that might be very slow because of the total number of positions being so large.\r\n\r\nOf course, an actual 24-dimensional table would not be practical to generate. For each position, you would probably want to just find the distance to the closest of the 24 positions. Or even simpler, just get the distance to each of the 24 positions until you find one that\'s less than or equal to 12, if you\'re satisfied with merely getting that result.\r\n\r\nI further note that the 24 H-symmetric positions (which include the four M-symmetric positions) on Reid\'s site are cube group positions, not edge group positions. I believe these correspond to only 8 different positions within the edge group (two 6H positions and two 6H+Superflip positions, in addition to the four M-symmetric positions). I think it is rather questionable if 8 edge group positions would be enough. I also note that just over one-fourth of the edge group positions are 12q or less from the solved position, so it would take a minimum of four fixed positions to have any chance of having every edge group position to be within 12q of at least one of the fixed positions, assuming very little overlap in \"coverage\" by each of the four fixed positions. I believe generally you will have rather significant overlap in the positions \"covered\" by any pair of the fixed positions.','70.22.176.109',1171230768,0,0,'1.2.1.1.1/','a:1:{i:0;i:0;}'),(301,0,73,2,'It\'s good to see this develop','It\'s good to see this development! A lot of work has gone into it.\r\n\r\nIt would be nice to see this algorithm in action, without having to calculate the huge tables for each phase. Have you considered making a solver that uses IDA* (with relatively small pruning tables) for each of the 5 stages separately?','130.88.73.18',1172077425,0,0,'1/','a:1:{i:0;i:0;}'),(302,301,73,31,'Re: It\'s good to see this develop','> It would be nice to see this algorithm in action, without
I have thought about this, but so far I haven\'t worked on implementing an IDA* solver for these stages.\r\nI will first be updating my solver so that it will allow a choice of metrics at runtime,\r\nas long as the corresponding (very large) data files are available.\r\nUnfortunately, the large sizes of these files causes problems with distribution,\r\nand it will take some effort to fix up the program to allow these files to be easily generated by users automatically.
\r\n\r\nSo using IDA* with relatively small pruning tables as you mentioned would be a reasonable way to provide a solver that uses these five stages, and that can easily be distributed. It might also be nice to have the solver try multiple solutions at each stage to find closer to optimal overall solutions.\r\nI don\'t know if I will get to doing this very soon, though.
\r\n\r\nI\'ll note that C. W. Tsai has created 7- and 8-step 4x4x4 solvers of the type you mention.\r\nHis solvers get the centers solved and edges paired up so that the remainder of the solve\r\nis done like a 3x3x3, enabling the use of Thistlethwaite\'s 3x3x3 subgroups for the remaining steps.\r\nSee \r\nhttp://www.geocities.com/c_w_tsai/solver4/.
\r\n','70.22.176.109',1172122556,0,0,'1.1/','a:1:{i:0;i:0;}'),(303,0,74,2,'Notation is often a headache...','Thanks for the setting out the details here. There is probably no \"perfect\" notation, but I hope that people will adopt the Schoenflies symbols for the symmetry classes: the basic symbols are already widely used (e.g. by chemists) and they contain useful mnemonic cues. But it would be nice to have something easier to remember than the modifiers (a1), (a2), etc.\r\n\r\nAs for the symmetry elements themselves, one might use Schoenflies symbols for them, but the notation used in Jaap\'s symmetry pages is easy to remember (r4, r3, r2e, mf, etc.), and easy to type, too.\r\n\r\nFor private use, I prefer International notation (the IUCr version of Hermann-Mauguin notation), with added subscripts f and e to distinguish the two kinds of two-fold axes and mirror planes. That\'s mainly because International notation was the one taught to me by crystallographers; but it does also have the small advantage of having a standardized, simple way to specify magnetic (antisymmetry) classes. However, it is awkward for typing: overbars are needed for rotation-reflection axes, and underlines for antisymmetries.','130.88.73.18',1172230554,0,0,'1/','a:1:{i:0;i:0;}'),(304,303,74,28,'In the Hoey taxonomy, now exp','In the Hoey taxonomy, now explained, I do not see as many mnemonic clues as in the Schoenflies notation,so I prefer the last. Indeed I also do not like the modifiers a1, a2, a and b, whose names I introduced totally arbitrary. The solution of striking simplicity has not been found yet, probably it does not exist at all.','84.167.127.207',1172356558,0,0,'1.1/','a:1:{i:0;i:0;}'),(305,0,75,34,'Its nice to see that the numb','Its nice to see that the number of symmetric cubes corresponds to the ones posted by Herbert on my symmetric cube article. Did you do the whole calculation again or did you have the number of symmetric cubes stored from before?\r\n\r\nRegards,\r\n\r\nSilviu','193.171.35.201',1172585712,0,0,'1/','a:1:{i:0;i:0;}'),(306,305,75,23,'From Before','This was all from before. I\'ve had all the symmetry data out to 10f and 12q since about 1997. Extending to 11f and 13q was a little more recent.\r\n\r\nIt\'s just that it made no sense to post the data until I had some reasonable way to describe the symmetry classes. That reasonable way arrived because Dan Hoey gave me permission to post his taxonomy and because I found Herbert Kociemba\'s description of his use of Shoenflies symbols in Cube Explorer.\r\n\r\nBy the way, I agree that Shoenflies symbols are the best way to go in the future, even though no system is perfect. However, some of the names in Dan Hoey\'s taxonomy do make mneumonic sense. That\'s because he tried to relate names for certain symmetry classes to the corresponding names for certain pretty cube patterns. For example, certain cubes with H\'s for faces may have H symmetry and certain cubes with X\'s for for faces may have X symmetry. I do not remember all the details of how this was worked out. But there are too many different symmetry classes for all of them to make sense. Many of the names in the taxonomy are clearly arbitrary.\r\n\r\nAnother aspect of the taxonomy that makes sense is that many of the two letter names in the taxonomy are based on sort of \"combining\" two of the one letter names. Symmetry can be calculated separately for the corners and the edges. Just as we can calculate Symm(x) for the entire cube, we can calculate Symm(xc) for the corners and Symm(xe) for the edges. Then, it\'s the case that Symm(x) = Symm(xc) intersect Symm(xe).\r\n\r\nIt\'s my experience that the eye can often see the symmetries of the corners and the symmetries of the edges separately, and therefore that the eye often perceives a position as having more symmetry than a straightforward calculation of Symm(x) would suggest. For example, if Symm(xc)=A1 and Symm(xe)=X1, then we have that Symm(x)=AX1. But I think the eye perceives both the A1 symmetry and the X1 symmetry, not just the lesser AX1 symmetry.','198.146.200.242',1172603025,0,0,'1.1/','a:1:{i:0;i:0;}'),(307,0,67,31,'Make that 83 twists','During the process of trying out the 85-twist,\r\nfive-stage procedure for solving the 4x4x4,\r\nI noticed that the generated solutions for\r\nrandom scrambles contained twist sequences\r\nthat could obviously be optimized.\r\nWhile this was to be expected across stage boundaries,\r\nthere were such sequences that\r\nwere not across a stage boundary.\r\nThese were three-twist sequences that\r\ncould be shortened to two twists.\r\nFor example, F2 and f are allowable\r\nsingle-slice turns for stages 2 and 3.\r\nThe combination (F2 f) could be achieved\r\nby substituting (Ff) F\' for f,\r\nso (F2 f) could be done as three twists,\r\nF2 (Ff) F\'.\r\nOf course, the same can be done with only two twists, (Ff) F.\r\n\r\n
Thus, I have now done a new calculation for stages 2 and 3\r\nthat allow the following double-twist moves\r\nalong with the other moves allowed before:
\r\n (Ff) F = F2 f
\r\n (Ff)\' F\' = F2 f\'
\r\n (Bb) B = B2 b
\r\n (Bb)\' B\' = B2 b\'
Of course, these double-twists count as 2 twists.
\r\n\r\nThe result of these analyses reduces\r\nthe maximum number of twists for these stages\r\nfrom 19 to 18 for each stage.\r\nThis reduces the upper bound to solve the 4x4x4 from 85 to 83.\r\nThe summary for these analyses is given below.
\r\n\r\n\r\nStage 2\r\n\r\ndistance positions unique\r\n 0 24 14\r\n 1 24 6\r\n 2 168 30\r\n 3 1,296 197\r\n 4 9,564 1,307\r\n 5 70,402 9,136\r\n 6 495,508 62,895\r\n 7 3,369,218 423,478\r\n 8 22,165,448 2,775,775\r\n 9 136,299,902 17,047,938\r\n 10 711,992,120 89,016,697\r\n 11 2,580,017,520 322,533,475\r\n 12 5,239,924,216 655,047,340\r\n 13 6,401,953,318 800,311,196\r\n 14 4,936,417,944 617,095,579\r\n 15 1,489,502,272 186,205,974\r\n 16 99,551,228 12,448,635\r\n 17 1,074,172 134,686\r\n 18 3,056 452\r\n ------------- -----------\r\n 21,622,847,400 2,703,114,810\r\n\r\nStage 3\r\n\r\ndistance positions unique\r\n 0 12 7\r\n 1 0 0\r\n 2 24 6\r\n 3 240 37\r\n 4 1,628 249\r\n 5 12,816 1,707\r\n 6 91,220 11,712\r\n 7 588,372 74,258\r\n 8 3,577,144 448,878\r\n 9 20,949,282 2,623,065\r\n 10 123,046,976 15,390,083\r\n 11 715,681,378 89,480,692\r\n 12 3,354,929,964 419,408,897\r\n 13 8,955,143,808 1,119,461,407\r\n 14 7,831,924,984 979,053,519\r\n 15 2,108,992,906 263,651,195\r\n 16 68,139,010 8,521,984\r\n 17 6,085,140 761,574\r\n 18 1,096 150\r\n -------------- -------------\r\n 23,189,166,000 2,898,889,420\r\n\r\n','70.22.176.109',1172637501,0,0,'1/','a:1:{i:0;i:0;}'),(308,0,77,2,'Correction:','Three of the depth-31 positions are self-inverse. Not four.','130.88.73.18',1172854894,0,0,'1/','a:1:{i:0;i:0;}'),(309,0,79,23,'Memories','
\r\nFirst of all, congratulations on applying antisymmetry to the 2x2x2 problem.\r\n
\r\n\r\nYour message really brought back some memories. At the time I did the original work on applying symmetry to the 2x2x2 problem, I knew very little about group theory. It was just that I was a pretty good programmer, and I had a pretty good intuitive feel for symmetry. Plus, I had to do something to reduce the size of the search space because I was working on a 286 PC running DOS with 512K memory and a 5MB hard disk. Of course, at that time the 286 PC\'s were brand new and were huge as compared to their predecessors.\r\n
\r\n\r\nMy use of the term B-conjugation was a misnomer, kindly corrected by Dan Hoey. What I was doing was starting with the corners of the 3x3x3 and reducing the search space as follows. For each position x, I was calculating a representative as the minimum of mxn, for all m and n in M (the set of 48 rotations and reflections), and where m and n both had to be rotations or both had to be reflections. Since this process is not conjugation, it can\'t be called B-conjugation.\r\n
\r\n\r\nDan showed that this process was equivalent to calculating the minimum of (m-1xm)c for all m in M and for all c in C (the set of 24 rotations). It\'s the inclusion of the c rotation that reduces the search space by 24 times, and the inclusion of M-conjugation that reduces the search space by about 48 times, for a total reduction of about 1152.\r\n
\r\n\r\nIn as sense, I had started with a problem that was 24 times bigger than it needed to be and reduced it by 1152 times. I think now that I would have been better off starting with a problem that was just as big as it needed to be and reducing it only by 48 times. The size of the resulting search space would be the same.\r\n
\r\n\r\nAs has been pointed out numerous times and places, the way to start out with a model for the 2x2x2 that starts out the right size is to generate the 2x2x2 by something like <U,L,F> rather than generating it as <U,L,F,D,R,B>. However, this model creates a new question that I\'ve never quite been able to figure out. I\'m probably just not thinking about the problem correctly, and perhaps one of you all can help me figure it out.\r\n
\r\n\r\nI can\'t figure out how M-conjugation can reduce the search space by 48 times for the <U,L,F> model. For example, let x be an element of <U,L,F>. Then xm may not even be in <U,L,F>. But if x is an element of <U,L,F,D,R,B>, then xm is guaranteed to be in <U,L,F,D,R,B>.\r\n
','198.146.200.216',1174920663,0,0,'1/','a:1:{i:0;i:0;}'),(310,309,79,31,'Re: memories','Basically, I had used the <U,L,F,D,R,B> model of 40320*2187 = 88179840 positions to do my calculations. I wrote my program to generate lookup tables to convert from those 88179840 positions to 77802*1152 sym-coordinates or 40296*2304 \"antisym-coordinates,\" while also building a reverse-mapping lookup table to map the 77802*1152 sym-coordinates or 40296*2304 antisym-coordinates back to the 88179840 positions. These tables required a whopping 724,087,296 bytes.
\r\n\r\nThe antisymmetry version of the code would take each position x in <U,L,F,D,R,B> and calculate (m-1xm)c and (m-1x-1m)c for all cube rotations c and all cube symmetries m. An alternate version calculated (m-1xm)c and ((m-1xm)c)-1, which also also seemed to work.
\r\n\r\nAfter Jerry\'s response, I went back to look at using <U,R,F> (essentially equivalent to using <U,L,F> as suggested by Jerry). Instead of generating mapping tables in both directions, I simply created a mapping table from the 3674160 positions to the 40296 classes. So for a position x in <U,R,F>, the program would compute (in <U,L,F,D,R,B>-space) all positions of the form (m-1(xc)m)q and (m-1(xc)-1m)q for all cube rotations c and all cube symmetries m, and where q represents the cube rotation required to put the resulting cube back into a <U,R,F> position. All the resulting <U,R,F> positions were mapped to the same class index as x. This process continued with all <U,R,F> positions not yet assigned to a class. So the mapping table in this case was only 14,696,640 bytes. This reduces the storage required, but in applying every cube rotation to the positions in <U,R,F>, it is still essentially reducing from <U,L,F,D,R,B>-space.
\r\n\r\nLater, I reran the program, except without applying the \"q\" cube rotation, essentially ignoring all resulting positions not in the <U,R,F>-space. This still produced the same 40296 classes. This reduces execution time, but is still essentially based on reducing from the <U,L,F,D,R,B>-space. It may be possible to simplify this further, but I haven\'t investigated any further.
\r\n','70.19.222.201',1175261530,0,0,'1.1/','a:1:{i:0;i:0;}'),(311,0,81,23,'Relations','I believe that the concept you are calling irreducible loops is called relations in Cube-Lovers. For example, check out \r\n\r\nhttp://www.math.rwth-aachen.de/~Martin.Schoenert/Cube-Lovers/Dan_Hoey__No_short_relations_and_a_new_local_maximum.html\r\n\r\nhttp://www.math.rwth-aachen.de/~Martin.Schoenert/Cube-Lovers/Dan_Hoey__Generating_Rubik\'s_Cube.html\r\n\r\nhttp://www.math.rwth-aachen.de/~Martin.Schoenert/Cube-Lovers/Dan_Hoey__Presenting_Rubik\'s_Cube.html\r\n\r\n\r\nThis notion is very much tied to \"duplicate positions\" that arise in a breadth first search of cube space. It\'s not really the positions that are duplicate; it\'s the multiple maneuvers that create the same position that create the \"duplication\". In any case, if you think in terms of traversing a Cayley graph for a particular set of generators for a group, you do have to be very careful to visit each node of the graph only once (or if you visit each node more than once, to count only one visit).\r\n\r\nAs a trivial example of duplicate positions, RL=LR. It\'s obviously the case that from RL we can get back to Start simply by saying (RL)(L\'R\'). It\'s almost as obvious or trivial that from RL we can get back to Start by (RL)(R\'L\') because moves of opposite faces commute. But (RL)(L\'R\') simply lists the inverses of the generators in reverse order to get back to Start, and (RL)(R\'L\') does do something slightly different. Namely, (RL)(R\'L\') takes advantage of the fact that RL=LR and combines RL with the inverse of LR.\r\n\r\nI think the case of DDDD=DD(D\'D\') that you cite is a little more interesting. From DD, you can go forward to Start via (DD)(DD), or you can go back to Start via (DD)(D\'D\'). The back to Start case is not very interesting, but the forward to Start case is interesting, even for a such a trivial example as DDDD. It\'s the \"forward to Start\" cases that correspond to duplicate positions. In this case, the duplicate positions are DD and D\'D\'. So you combine DD with the inverse of D\'D\', and you get (DD)(DD) to go forward to Start from DD.\r\n\r\nThe way I think of it is that any time you find duplicate maneuvers for the same position you can create a relation. And from half way through a relation, you can find duplicate maneuvers for the same position (provided of course that your relation doesn\'t simply list the inverses of the generators in the opposite order like RLL\'R\').\r\n\r\nTo the best of my knowledge, nobody really knows how many unique relations there are, nor even precisely how to define \"unique\". For example, are relations unique if they differ only by commuting moves from opposite faces? Are relations unique if they are reducible in trivial way (and what is a \"trivial way\"). Are relations unique if they contain segments that can be replaced by symmetrical segments? Are relations unique if they contain segments that can be commuted?\r\n\r\nI have thought about at least trying to come up with a definition for \"unique\" in this context, but I\'ve never come up with anything I\'m happy with. So I content myself with brute force detection of duplicate positions as exemplified by positions whose Starts-With and/or Ends-With values include more than one generator. And as I have posted previously, the ability to calculate Starts-With and Ends-With is just an artifact of the way I do a breadth first search of Cube space.\r\n\r\nFinally, it has always seemed to me that the problem of finding relations really just recasts the problem of finding God\'s Algorithm in new language. It feels like it\'s still the exact same problem, still just as difficult. I could be wrong, but that\'s the way it seems. That\'s because to me the fundamental God\'s Algorithm problem is duplicate positions. Were it not for duplicate positions, God\'s Algorithm would be easy. And I think that duplicate positions and relations are just two sides of the same coin.\r\n','71.203.230.238',1176949902,0,0,'1/','a:1:{i:0;i:0;}'),(312,0,81,4,'Hi,','Hi,\r\n\r\nI\'ve written a little bit about this kind of thing on my website too, on a page about Cayley graphs:\r\nhttp://www.geocities.com/jaapsch/puzzles/cayley.htm\r\n\r\nSuch a loop in the graph represents an identity (a move sequence with no effect), and I called them irreducible identities.\r\n\r\nThe Rubik\'s Cube is not the best kind of puzzle for this technique because there are very long irreducible identities. Ideally you\'d want a puzzle which has many short identities, preferrably because many of the moves commute. I proposed the Cmetrick and the Gripple puzzles as good candidates, but never got around to trying that out. The Cmetrick has since been calculated through using more traditional methods.\r\n\r\nJaap\r\n\r\nJaap\'s Puzzle Page: http://www.geocities.com/jaapsch/puzzles/','83.86.171.170',1177362521,0,0,'2/','a:1:{i:0;i:0;}'),(313,312,81,23,'The Dangling String Analogy','I\'ve been very fond of Jaap\'s Web site for a long time, and I\'m especially fond of his Cayley Graph page mentioned above (the one at http://www.geocities.com/jaapsch/puzzles/cayley.htm). I particularly like his Dangling String analogy.\r\n\r\nLet me quote one sentence from the Dangling String analogy: \"Cayley graphs are uniform, so this dangling string net will look exactly the same regardless of which node you picked it up at.\"\r\n\r\nThe quote from Jaap\'s Web site is exactly correct, or course. However, I\'m embarrassed to say that when I first started working on Rubik\'s Cube I knew so little group theory that I would have sworn that a graph of Cube space was not uniform. In fact, there are several posts that I made to Cube-Lovers that reflect this incorrect point of view, and I dearly wish I could retract those posts.\r\n\r\nIn my defense, there was a somewhat reasonable basis for my mistake, especially since I knew so little group theory. None of my cube programs have ever searched a complete Cube space. Rather, my programs have always searched a space that is Cube space reduced by symmetry. It never occurred to me to search a complete Cube space because a complete Cube space is so much larger than the equivalent Cube space reduced by symmetry.\r\n\r\nCube space reduced by symmetry is not a group and is not uniform. For example, when Cube space is reduced by symmetry, the Start position in the quarter turn metric has only 1 neighbor rather than 12, and the Start position in the face turn metric has only 2 neighbors rather than 18. Hence, a Dangling String model of Cube Space reduced by symmetry will look very different depending on which node you pick it up at. But in my early naive posts to Cube-Lovers I didn\'t realize that such a reduced search space was not a group.','198.146.200.157',1177610020,0,0,'2.1/','a:1:{i:0;i:0;}'),(314,313,81,4,'Thanks for those complimentar','Thanks for those complimentary words, Jerry.\r\n\r\n> Cube space reduced by symmetry is not a group and is not uniform.\r\n\r\nThat\'s correct.\r\nIt is a coset space (or quotient space) that the group acts on by ordinary group multiplication.\r\n\r\nLast Monday I presented a guest lecture for first year mathematics students. They had learnt the beginnings of group theory (cosets, actions, but not yet normal subgroups), and I was asked to give a talk that showed them what it all means.\r\n\r\nIf you don\'t mind, I\'ll write some of it out below. It is something I want to add to my site some time, and I\'ll use this opportunity to put some of it into words.\r\n\r\nOne of the things I presented was the Rubik\'s Cube. There is an obvious action here - the group of permutations acts on the set of positions. Given any permutation you can apply it to a position to get another position.\r\n\r\nThis action is free, meaning that if the permutation actually moves something then the position will change. This leads to the conclusion that the number of permutations in the group is exactly the same as the number of positions you can reach.\r\n\r\nThen do the same with a cube that has only three colours, each layer a different colour. Now permutations sometimes seem to do nothing, for example turning one of the monochrome layers when in the solved position. It moves pieces, but you can\'t see it.\r\n\r\nSuppose you apply a permutation g to the starting position. You would get the same result if you did a permutation h that kept the starting position looking the same before applying g. So g and hg have the same effect on the starting position, where h is an element of the stabiliser of the starting position.\r\n\r\nLet H be the stabiliser of the starting position. All elements of Hg all look the same as g when applied to the starting position. In fact, you can actually say that each coset Hg represents a position, with H itself representing the starting position. \r\n\r\nThe coset space H\\G = {Hg | g in G} represents all the positions the puzzle can have. G acts on this set by right-multiplication.\r\n\r\n\r\nReducing the cube space through symmetry is actually no different. Here you use H as the group of cube rotations and reflections. These are permutations of the 54 cube stickers that leave the position looking the same (just in a different orientation in space). When you reduce the cube space by symmetry, you are actually looking at the coset space of H\\G, treating each coset as a single position. \r\n\r\nAs you\'ve noticed, the \'Cayley graph\' of a coset space is usually not uniform, as it does not form a group. When it does form a group, then H\\G is called a quotient group and H is called a normal subgroup of G.\r\n\r\nI wonder whether it is possible for a coset space to not be a group, but to still have a uniform graph.\r\n\r\n\r\n\r\nJaap\r\nJaap\'s Puzzle Page: http://www.geocities.com/jaapsch/puzzles/','134.146.0.12',1177660230,0,0,'2.1.1/','a:1:{i:0;i:0;}'),(315,314,81,23,'Cube Space Reduced by Symmetry','I think some clarification is needed. We may not be meaning the same thing as each other when we say \"cube space reduced by symmetry\".\r\n\r\nThe way I do it, the full cube space is partitioned into equivalence classes by symmetry, and the equivalence classes are not cosets. The smallest example I can think of to illustrate would be something like the group <F>={I,F,F2,F-1}.\r\n\r\nReducing this group by symmetry only reduces it from 4 elements in the group to 3 equivalence classes, namely {I}, {F,F-1}, and {F2}. These 3 equivalence classes are not all the same size, and they definitely are not cosets.\r\n\r\nIs there another interpretation of \"cube space reduced by symmetry\" that can be modeled with cosets?','198.146.200.157',1177694211,0,0,'2.1.1.1/','a:1:{i:0;i:0;}'),(316,315,81,23,'Oh, and as a part of the \"cla','Oh, and as a part of the \"clarification\", I should mention that I do understand your example of the three colored cube, and your example definitely is cosets. It\'s just that reducing the number of colors is not what I normally think of when I think of \"reducing the search space by symmetry\". It is reducing the search space, but it feels like it\'s reducing it by something other than symmetry, I just don\'t know what to call it.\r\n\r\nLet me come at this from a slightly different direction. Consider what I have been calling partial permutations and what Cube Explorer calls incomplete cubes. In terms of modeling this concept on an actual physical cube, I think of it as graying out certain of the cubies. And graying out of certain of the cubies may certainly be thought of in terms of cosets.\r\n\r\nTo match your three color model, suppose we take a cube in the Start position, gray out the top layer, and scramble the cube. Any resultant position may certainly be thought of as a coset. Suppose we then return to the Start position, gray out the top layer, and gray out the middle layer with another shade of gray. We get cosets again, and I\'m just using shades of gray the same way you are using your three colors.\r\n\r\nNow, let\'s return to the Start position and gray out seven of the corner cubies and all twelve edge cubies (all with the same shade of gray). If you scramble this incomplete cube, there are 24 different positions in which the corner cubie that is not grayed out can be placed. And those 24 different positions correspond to 24 cosets. The subgroup of which they are cosets is the subgroup that fixes the corner cubie that is not grayed out.\r\n\r\nI would then go further and reduce those 24 positions by symmetry. For example, suppose the corner cubie that were not grayed out were the flu cubie and suppose the flu cubie were in its Start position in the flu cubicle. I would regard the position of the flu cubie after the six following moves (applied to Start in each case) to be an equivalence class under symmetry: F, F\', L, L\', U, U\'.','198.146.200.157',1177697291,0,0,'2.1.1.1.1/','a:1:{i:0;i:0;}'),(317,316,81,4,'I got confused again.\r\nYou\'re','I got confused again.\r\nYou\'re right, and things are not so simple as I made them out to be. The problem is that rotations and reflections of the cube are not only permutations of the stickers, they also redefine what the moves are. In other words, the recolouring of the centres messes things up.\r\n\r\nIn the 3-colour cube case we had a coset H representing the solved cube, and if we apply moves g1 and then g2 to it we get H.g1.g2, a different coset. The group G acts on the cosets in this way by right-multiplication.\r\n\r\nIn the cube reduced by symmetry case we have something different. Let H be the set of rotations/reflections of the cube as a permutation of the 54 facelets. After applying g1 to the solved position we get g1.H as the set of all legal sticker permutations that represent the same position. When we apply another move g2 we get g1.g2.H, and this is not an action in the same way as before.\r\n\r\nLet\'s take a particular element of the set g1.g2.H, say g1.g2.h, i.e. two moves followed by a cube rotation. We can rewrite this as h.(h\'.g1.h).(h\'.g2.h), where h\' is the inverse of h. Since the initial h has little effect on the solved position (except to swap colours), this is just as if two moves were performed, but not g1 and g2 themselves but g1 and g2 changed under the rotation/reflection h.\r\n\r\nThis cube symmetry stuff keeps tripping me up.\r\n\r\nJaap\r\nJaap\'s Puzzle Page: http://www.geocities.com/jaapsch/puzzles/','134.146.0.12',1178007453,0,0,'2.1.1.1.1.1/','a:1:{i:0;i:0;}'),(318,0,83,4,'Cubelet flip','Hi,\r\n\r\nI hadn\'t heard the term \"O point group\" before (googling seems to show it is used in chemistry), but I assume it means the group of 24 rotations of a cube (or cubelet).\r\n\r\nIt is possible to define what edge flip means within this group. When a cubelet is rotated, this can be considered as a permutation of its 6 facelets. Call a cubelet flipped if its facelets have undergone an odd permutation. The 24 rotations then break down into two sets of 12 - one set flips a cubelet, the other doesn\'t.\r\n\r\nNo flip:\r\n identity\r\n the eight 60 degree rotations about a vertex\r\n the three 180 degree rotations about a face centre\r\nFlip:\r\n the six 180 degree rotations about an edge\r\n the six 90 degree rotations about a face centre\r\n\r\nNote that this is consistent - two flip rotations combine to give a no-flip rotation, two no-flip rotations combine to a no-flip rotation, and flip plus no-flip gives flip.\r\n\r\nAny quarter turn move on the cube flips 4 edge cubelets. Before the move, 0,1,2,3 or 4 of those edge cubelets could have already been in a flipped state, and after the move there will then be 4,3,2,1, or 0 edge cubelets in a flipped state respectively.\r\n\r\nNote that the number of flipped cubelets remains odd or remains even, regardless of the move. As the solved cube has by definition no flipped edge cubelets, there will always be an even number of flipped edge cubelets when it is mixed.\r\n\r\nA \'twisted two-cycle\' will indeed flip two edges when performed twice, but when done only once it will flip exactly one edge cubelet. As I just showed, that is not possible to do without also flipping other edge cubelets.\r\n\r\n\r\nCorner twists are rather more messy. It is unfortunately not possible to define cubelet twist by looking only at the rotation without taking the cubelet location into account.\r\n\r\n\r\nJaap\r\nJaap\'s Puzzle Page: http://www.geocities.com/jaapsch/puzzles/','83.86.171.170',1179397222,0,0,'1/','a:1:{i:0;i:0;}'),(319,0,84,28,'Sorry, should be Round[(3+r)(','Sorry, should be Round[(3+r)(6+3r)^n /4]','84.167.100.35',1179589130,0,0,'1/','a:1:{i:0;i:0;}'),(320,319,84,4,'A little explanation','That\'s quite nice.\r\n\r\nI assume you first constructed the recurrence relation:\r\n\r\ns(n) = 3*4*s(n-1) + 3*3*2*s(n-2)\r\n\r\nHere I use s(n) for the number of manoeuvres of length n. The last two moves of the move sequence are either adjacent or opposite faces. If adjacent, you simply extend a sequence of n-1 moves with a move on one of the 4 faces adjacent to the last move. This gives the first term.\r\nIf opposite, you extend a sequence of n-2 moves with two opposing moves on one of the 2 axes other than the last move. This gives the last term.\r\n\r\nPut in the boundary conditions:\r\ns(1) = 18\r\ns(2) = 243\r\n\r\nand you get your formula. Unfortunately the formula gives s(0)=3/2, but that is because the relation breaks down:\r\n\r\ns(2) = 3*4*s(1) + 3*3*3*s(0)\r\n\r\nThere is a factor 3 instead of 2 in the last term because there is no previous move and all 3 axes are available for the pair of opposite moves.\r\n\r\n\r\nJaap\r\nJaap\'s Puzzle Page: http://www.geocities.com/jaapsch/puzzles/','83.86.171.170',1179596612,0,0,'1.1/','a:1:{i:0;i:0;}'),(321,320,84,28,'You are right, I overlooked t','You are right, I overlooked that N(0) gives 3/2.\r\nMy way was a bit more complicated, I startet with a(1)=9 and b(1)=9 and used the recurrence\r\n\r\na(n+1) = 6*a(n) + 9*b(n) and\r\nb(n+1) = 6*a(n) + 6*b(n)\r\n\r\n\r\nHerbert','84.167.100.35',1179598649,0,0,'1.1.1/','a:1:{i:0;i:0;}'),(322,318,83,106,'Flip cycles','Thanks for your comment.\r\n\r\nO is the Schoenflies designation for the group, commonly used by chemists of which I am one.\r\n\r\nOk. It makes sense. If there is a cycle, (a,b,c,d . . . ) = C2 the product ...[d][c][b][a] must have odd parity. This means an odd number of the terms have odd parity. Since a,b,c .. are the rotational states of the cubelets involved in the cycle, at this point in the cycle an odd number of them are flipped. Thus there must be another C2 cycle to even the total parity.\r\n\r\nI hadn\'t realized it before but a cubelet\'s flip is given by the A2 representation of its rotational state. You\'ve allowed me to simplify my program. I\'ll have to have another look at corner twist, there must be a simple way to pull it out of the character table.\r\n\r\nAgain, thank you.\r\nBruce MacKenzie','74.137.194.164',1179605272,0,0,'1.1/','a:1:{i:0;i:0;}'),(323,0,84,23,'Cube Lovers Bounds','The best Cube Lovers bounds may be found at:\r\n\r\nhttp://www.math.rwth-aachen.de/~Martin.Schoenert/Cube-Lovers/Dan_Hoey__The_Supergroup_--_Part_2__At_least_25_qtw,_and_why.html\r\n\r\nhttp://www.math.rwth-aachen.de/~Martin.Schoenert/Cube-Lovers/Dan_Hoey__Re__Updated_Upper_Limits,_Q-turns.html\r\n\r\nhttp://www.math.rwth-aachen.de/~Martin.Schoenert/Cube-Lovers/Dan_Hoey__Re__lower_bounds.html\r\n\r\nThe first two messages address the quarter turn metric. The last message addresses the face turn metric.','71.203.230.238',1179712886,0,0,'2/','a:1:{i:0;i:0;}'),(324,320,84,23,'Boundary Conditions','When I have played with this before, I have come the conclusion that the asymptotic branching factor turns out to be the same, irrespective of what boundary conditions are used. Obviously, it\'s nice to use the correct boundary conditions, but you get the same asymptotic branching factor even if you don\'t.\r\n\r\nThis has some interesting implications if you start with what is known and project out to what is not known. For example, the number of positions is currently known out to 11 face turns from Start. The actual branching factor tends to decline slightly as you get further from Start, until finally it declines sharply as you get close to the diameter. The decline in actual branching factor corresponds to an increased number of duplicate positions as you get further from Start, which in turn corresponds to the effects of longer relations (c.f., the recent thread on Irreducible Loops).\r\n\r\nFor example, the actual branching factor from 10f to 11f is about 13.19..., which is a bit less than the asymptote of about 13.348... The 13.19... figure is 3063288809012/232248063316. But if you plug in 232248063316 and 3063288809012 as boundary conditions, then both Herbert\'s formula and Dan Hoey\'s formula quickly revert back to the asymptotic branching factor of about 13.384 if you project out to 12f from Start, 13f from Start, 14f from Start, etc.\r\n\r\nI have wondered if it might be possible to come up with a formula that actually isn\'t asymptotic, and that reflects different boundary conditions. In other words, might it be possible to come up with a formula where the projected branching factor would continue to decline further from Start. For example, starting with the actual branching factor of about 13.19... going from 10f to 11f, might it be possible to find a formula for which the projected branching factor would continue to decline in going to 12f, 13f, 14f, etc. I have a few very rough ideas, but I\'ll put the details in a separate thread.','71.203.230.238',1179717419,0,0,'1.1.2/','a:1:{i:0;i:0;}'),(325,321,84,2,'Complication is in the eye of the beholder','> My way was a bit more complicated\r\n\r\n...but it has the advantage that the boundary condition is simpler. (I used the same method, btw, after failing to understand the description in Singmaster\'s Notes.)\r\n\r\nIt would be nice if this were done for a shape-changing puzzle such as Square-1. It\'s no more difficult -- in principle! -- but the matrix M on the r.h.s. of\r\n\r\n(vector) a(n+1) = M.a(n)\r\n\r\nis large, because of the multiplicity of shapes, and its eigenvalues and eigenvectors would (probably) have to be found numerically. As in the case of the Cube, the asymptotic b.r. will just be the largest eigenvalue of M.','130.88.73.18',1179757057,0,0,'1.1.1.1/','a:1:{i:0;i:0;}'),(326,0,85,23,'A Different Recursion Formula','Well, I did find that I had already posted about branching factors for individual positions. Sorry for the duplication. But it\'s probably just as well, because I had wanted to post an alternate recursion formula for the number of positions that are n moves from Start. The alternate formula depends on the branching factors of individual positions.\r\n\r\nIf T[n] is the number of positions that are n moves from Start, then an alternate recursion formula for the quarter turn metric is as follows.\r\n\r\n1. If n=0, then A[n]=1, and B[n]=C[n]=D[n]=E[n]=0\r\n2. If n>0, then\r\n A[n] = 0\r\n B[n] = 12*A[n-1] + 8*B[n-1] + 8*C[n-1] + 8*D[n-1] + 8*E[n-1]\r\n C[n] = 3*B[n-1]/2\r\n D[n] = 2*C[n-1]/3\r\n E[n] = 1*D[n-1]/4\r\n3. T[n] = A[n] + B[n] + C[n] + D[n] + E[n]\r\n\r\nThe recursion formula above is equivalent to the one that Dan Hoey posted to Cube Lovers (and that Herbert must have used in developing his own very nice formula, and that Jaap made reference to in his message about Herbert\'s formula). I would describe Dan\'s recursion as being based on what he called syllable analysis, where a syllable is a sequence of moves on the same or opposite faces (up to four such successive moves in the quarter turn metric and up to two such successive moves in the face turn metric). I would describe the formula above as being based on branching factor analysis, but of course the branching factor analysis can be derived from the syllable analysis and vice versa.\r\n\r\nHere\'s the way the formula above works. The Start position has a branching factor of 12 in the quarter turn metric. Suppose the first move is F. F has a branching factor of 11, which we write as 3+8. The next move can come either from the F-B faces or not. If it does come from the F-B faces, there are 3 choices and and if not there are 8 choices. If the second move is also from the F-B faces, the resultant position (e.g., FB) has a branching factor of 10 which we write as 2+8. The next move can come either from the F-B faces or not. If it does come from the F-B faces, there are 2 choices and if not there are 8 choices. If the third move is also from the F-B faces, the resultant position (e.g., FBF) has a branching factor of 9 which we write as 1+8. The next move can come either from the F-B faces or not. If it does come from the F-B faces, there is 1 choice and if not there are 8 choices. If the fourth move is also from the F-B faces, the resultant position (e.g., FBFB) has a branching factor of 8 which we write as 0+8. There are now 0 moves that can come from the F-B faces and we are forced to choose one of the 8 moves from the other faces. If at any time, we choose a move from one of the \"other\" faces, the branching factor goes back up to 11 which we write as 3+8 and the process repeats. The divisors in the formulas for C, D, and E are there to be sure that duplicate positions are counted only once.\r\n\r\nThe A[n] term takes care of the special case of the Start position. The B[n] term takes care of the \"+8\" part of the 3+8, 2+8, 1+8, and 0+8 cases. The C[n] term takes care of the 3 part of the 3+8 case. The D[n] term takes care of the 2 part of the 2+8 case. And the E[n] term takes care of the 1 part of the 1+8 case.\r\n\r\nThe formula of Dan Hoey et.al. is much simpler than the one above. The only reason I like the one above at all is that the value of T[n] depends explicitly only on the value of T[n-1], and therefore it relates directly to the branching factor of each position. In Dan\'s formula, the value of T[n] in the face turn metric depends explicitly on the values of T[n-1] and T[n-2], and in the quarter turn metric the value of T[n] depends explicitly on the values of T[n-1], T[n-2], T[n-3] and T[n-4].\r\n','71.203.230.238',1179887772,0,0,'1/','a:1:{i:0;i:0;}'),(327,0,85,28,'Another (dubious) approach to branching factors (FTM)','If we sum up the number of nontrivial maneuvers up to n moves we get in good approximation\r\n\r\ns[n] = (3/116)*(30 + 11*Sqrt[6])*(6 + 3*Sqrt[6])^n\r\n\r\nmoves.\r\nNow we generate all maneuvers with increasing length.\r\nIf we assume (what definitely is wrong) that each maneuver gives any of the n0 = 43252003274489856000 possible cube positions by random with the same probability, the probability that the next maneuver does not give a duplicate but a new position is proportional to the number of still not produces cubes. This is similar to the equation which describes radioactive decay and leads to some exponential function. It is not difficult to show, that this implies\r\n\r\nh[n] = 1 - Exp[-s[n]/n0]\r\n\r\nwhere h[n] gives the part of cubes we get within n moves, and h[n]-h[n-1] is fraction of the cube space we get with exactly n moves.\r\n\r\nFor small n h[n] is about s[n]/n0, which is obviously correct.\r\nTo see how the approximation is for bigger n we use Rockiki\'s result who optimally solved 22756 random cubes and got the following distribution for 14,..20 moves\r\n\r\n{0.0000439, 0.00163, 0.0254, 0.266, 0.670, 0.036, 0}\r\n\r\nh[n]-h[n-1] gives\r\n\r\n {0.000180, 0.00239, 0.0314, 0.336, 0.628, 0.0021, 1.84*10^-36}\r\n\r\nwhich is not too bad for a wrong assumption, especially for 16, 17 and 18 moves.\r\n','84.167.91.87',1179942493,0,0,'2/','a:1:{i:0;i:0;}'),(328,310,79,106,'2x2x2 Symmetries','Some thoughts occur to me concerning symmetry and the 2x2x2 cube. I would look upon one of the eight cubelets as fixed and the puzzle thus being the permutations of the other seven cubelets relative the eighth as a fixed reference. This would correspond to what you term the (U,L,F) model. The symmetry of the puzzle then becomes not cubic but trigonal pyramidal. One then only need consider six elements of symmetry, identity, two by rotation about the three fold axis, and three by reflection through the three vertical planes of symmetry. Would this not simplify the problem of finding equivalence classes or am I missing something?','74.137.194.164',1180058878,0,0,'1.1.1/','a:1:{i:0;i:0;}'),(329,328,79,23,'Horses and Cubes','What you are writing about is what I\'m trying to understand, and don\'t.\r\n\r\nIt seems to me that if two different models for the same problem are correct representations of the problem, then the two different models should yield the same answer. But in this case, it seems to me that we have two different models that ought to be equivalent but aren\'t. I\'m obviously missing something.\r\n\r\nIgnore symmetry for a second. The two models for the 2x2x2 seem to be:\r\n\r\n1. Consider one corner fixed.\r\n2. Do not consider any corners fixed, but consider any positions equivalent if they differ only by a whole cube rotation. This truly means differing by a single rotation, not differing by conjugation of rotations.\r\n\r\nModel #2 starts out being exactly 24 times larger than model #1. But when you consider positions equivalent if they differ only by whole cube rotations for model #2, then the size of model #2 is reduced by exactly 24 times. That means that model #1 and model #2 are exactly the same size, which is the expected outcome. Model #1 is simpler in several respects than model #2, but the two models yield identical results.\r\n\r\nSo far, so good. Now let\'s add symmetry. Conjugating by symmetry, model #2 can be further reduced by about 48 times. Conjugating by symmetry, model #1 can be further reduced by about 6 times (exactly as you point out). So model #2 is about 8 times smaller than model #1.\r\n\r\nI see where the factor of 8 is coming from. It\'s because model #2 is dealing with symmetries with respect to all 8 corners and model #1 is dealing with symmetries with respect to only one corner. But I\'m still making a dumb mistake.\r\n\r\nI\'m sure the mistake is something like the following \"proof\" that a horse has 8 legs: a horse has 2 front legs, 2 back legs, 2 left legs, and 2 right legs. 2+2+2+2 is 8, so a horse has 8 legs. The mistake in the horse proof is trivial to see, but I just can\'t quite see what\'s wrong with the way the size of the 2x2x2 problem is being calculated when it is reduced by symmetry.','71.203.230.238',1180061554,0,0,'1.1.1.1/','a:1:{i:0;i:0;}'),(330,329,79,106,'Reducing the 2x2x2 group by symmetry','The problem is that when one conjugates model 2 with the full 48 element cubic symmetry set one generates a whole lot of positions which differ from one another only by whole cube rotations and thus are the same position. These duplicates do nothing to reduce the search space.\r\n\r\nConsider model 1 with the left,down,back cubelet fixed in position. The six allowed symmetries all leave this cublet in place. The disallowed symmetries move this cublet to a different position. Thus [s\' m s] will in general not put the fixed cubelet back where it belongs. Thus the similarity transform produces an element not in the original group and is not valid. The same thing is occurring in model 2 but since no reference orientation is defined it is more difficult to see.','74.137.194.164',1180069289,0,0,'1.1.1.1.1/','a:1:{i:0;i:0;}'),(331,330,79,106,'Reducing the 2x2x2 group by symmetry','\r\nI\'ve been thinking about this a lot and I think I was wrong in my previous post when I implied using cubic symmetry to reduce the 2x2x2 group was invalid. I believe I see how to use full cubic symmetry to reduce the 2x2x2 group in the context of the fixed cubelet model.\r\n
\r\nOne must have a representation which represents all eight cubelets, one of which is designated as the reference cubelet. Let G be the group of all corner permutations using the full set of face turns and H be the subgroup of G generated using only the R,U,F face turns. H then contains all elements of G in which the reference cubelet, the ( l , d , b ) cubelet, is in the unrotated or E state.\r\n
\r\nAn equivalence class may be generated for each element h in H by applying similarity transforms using the elements of the cubic symmetry group:\r\n
\r\nei = ci-1 h ci for all elements, ci, of the cubic symmetry group.\r\n
\r\nNow as I pointed out in the previous post the set of elements generated above is not a valid equivalence class because in general the elements generated are not members of H. This is because the similarity transform may move and/or rotate the reference cubelet from the E state. However, since G has cubic symmetry and h is a member of G, the transformed elements will be members of G. Any element of G may be converted to an element of H by applying a whole cube rotation, i.e. the whole cube rotation which will place the reference cubelet in the E state. So, for each element ei a whole cube rotation must be applied to generate its corresponding element in H. The set of elements thus generated would then constitute the equivalence class--I think.\r\n
\r\nIn order for the above to be valid, the procedure must uniquely define each class. For this to be true it must not matter which element of the class one uses as the basis of the class--submit any member of the class to the above procedure and one will generate the same list of elements. Now I have been confusing myself with left cosets, right cosets, normal subgroups, etc. trying to convince myself this is the case, but I haven\'t yet. Perhaps someone with more facility with the abstract concepts of group theory than I could look at the above with a critical eye and help me out?\r\n
\r\nOrder of the corners of the 3x3x3 88179840\r\nOrder of the 2x2x2 3674160 (24 times reduction)\r\n2x2x2 reduced by symmetry 77802 (47.22 times reduction, about 48 times)\r\n\r\n\r\nSo the search space for the 2x2x2 really can be reduced about 48 times by symmetry rather than about 6 times, and I can\'t explain why to my satisfaction.','67.163.161.51',1180226368,0,0,'1.1.1.1.1.2/','a:1:{i:0;i:0;}'),(333,331,79,4,'My attempt to formalise this.','Let C be the group of rotations of the cube.\r\nWhen reducing the whole group G by cube rotations, we split G into sets C g C, g in G. \r\n
\r\nThe first cube rotation can be seen as a recolouring, the last cube rotation determines the orientation of the puzzle as a whole. All elements in C g C are deemed equivalent to g itself.\r\n
\r\nThese are easily shown to be equivalence classes.\r\n
\r\nC c1 g c2 C = C g C for any c1, c2 in C, and so it doesn\'t matter which element in the class is used to represent it.\r\n
\r\nYou said:\r\n
\r\nLet H be the subgroup of G generated using only the R,U,F face turns. An equivalence class may be generated for each element h in H by applying similarity transforms using the elements of the cubic symmetry group:\r\n\r\n\r\nI think so too. You just constructed the set:\r\n
\r\nei = ci-1 h ci for all elements, ci, of the cubic symmetry group.\r\n
\r\n[...], for each element ei a whole cube rotation must be applied to generate its corresponding element in H. The set of elements thus generated would then constitute the equivalence class--I think.\r\n
\r\nYou said:\r\n
In order for the above to be valid, the procedure must uniquely define each class. For this to be true it must not matter which element of the class one uses as the basis of the class--submit any member of the class to the above procedure and one will generate the same list of elements.\r\n\r\nWith the formulation above it is easy to show, in just the same manner as before for the whole group.\r\n
\r\nThe only remaining question now is, will the number of equivalence classes be the same in these two different formulations.\r\n
\r\nGiven an equivalence class of the second type, C h C intersected with H, it is easy to uniquely construct an eq. class of the first type, namely C h C.\r\n
\r\nThe other direction is only slightly trickier. Given an eq. class of the first type, C g C for some g in G. The reference piece is moved somewhere, but since C is transitive, we can follow it by a cube rotation c such that c g lies in H. From this we can of course construct C (cg) C intersect H, an eq. class of the second type. \r\n
\r\nSo these two formulations of sets of equivalent permutations are themselves equivalent. It is just that in the second formulation you use a smaller group of permutations, resulting in just as many smaller equivalence classes.\r\n\r\n
\r\nThings are not so different if we use use M instead of C, i.e. include the reflections as well. The only difference is that an equivalence class of the first type now becomes M g M intersect G. This is because reflection is not an operation that lies in G itself, just like the cube rotations in C were not in the group H. For M g M intersect G to make sense, we must of course work in a supergroup containing both G and M, for example the group S24.\r\n
\r\n\r\nJaap\r\n
\r\nJaap\'s Puzzle Page: http://www.geocities.com/jaapsch/puzzles/','83.86.171.170',1180266519,0,0,'1.1.1.1.1.1.1/','a:1:{i:0;i:0;}'),(334,333,79,106,'Reducing the 2x2x2 group by symmetry','
\r\nYour analysis is very interesting. I\'m trying to get my mind around what you\'re saying. I think visually. Symbols on paper lose their meaning unless I can visualize it, so bear with me.\r\n
\r\nYou said:
\r\n \"Let C be the group of rotations of the cube. When reducing the whole group G by cube rotations, we split G into sets C g C, g in G.\"\r\n
\r\nOk, CgC are sets generated by: ci g cj for all elements ci, cj in C. This is equivalent to ci (cj-1 g cj). The similarity transform, (cj-1 g cj), generates all the unique ways pattern g may be applied to the cube and ci are all the whole cube rotations which may be applied to each pattern ( or the different angles from which that pattern may be viewed ).\r\n
\r\nNow we\'ve been talking about reducing G using the full 48 element cubic symmetry group, what you refer to as M. So we want to look at equivalence classes as MgM intersect G. Restating MgM as I did above for CgC, the constructions of the sets follows:\r\n
\r\nmi(mj-1 g mj) for all elements mi, mj of M.\r\n
\r\nThe similarity transform: (mj-1 g mj) always generates an element of G--parity rules require that the product of a rotation and a reflection is always a reflection and the product of two reflections is always a rotation. Thus you don\'t have to worry about the transform producing inside-out cubelets. Reflection preserves twist parity so everything is OK. In order for the whole product to be a member of G, mi can\'t be a reflection. That is mi must be a rotation, an element of C. Thus the sets may be constructed as:\r\n
\r\nci(mj-1 g mj) for all elements ci of C and mj of M\r\n
\r\nSo MgM intersect G generates sets containing all the ways a pattern ( and its mirror image ) may be applied to the cube and all the different angles from which each may be viewed. So one may organize the elements of each equivalence set in G into subsets, each subset containing all the ways of viewing a particular result of (mj-1 g mj). Now the procedure I propose for generating equivalence sets in H starts by generating a set by:\r\n
\r\n(mj-1 h mj) for all elements mj of M\r\n
\r\nThis is precisely the same as the first part of the procedure for generating the equivalence sets in G. Thus the initially generated set contains one element from each subset of the set in G defined above. By applying a whole cube rotation the element in each subset which is a member of H is determined ( and there must be one since all orientations are included ) and thus becomes an element of the equivalence set in H. OK, good. I\'ve convinced myself that what you say is true. The equivalence sets generated are indeed (MgM intersect G) intersect H.\r\n
\r\nAll your other arguments for completeness etc. seem good. So I think the proposed procedure is sound and will give well formed equivalence sets in the fixed cubelet model.\r\n
\r\nThank you. After working through what you said, I think I understand things much better.\r\n
| Shell | \r\nClasses | \r\nElements | \r\n
| 0 | \r\n1 | \r\n1 | \r\n
| 1 | \r\n1 | \r\n6 | \r\n
| 2 | \r\n3 | \r\n27 | \r\n
| 3 | \r\n6 | \r\n120 | \r\n
| 4 | \r\n17 | \r\n534 | \r\n
| 5 | \r\n59 | \r\n2256 | \r\n
| 6 | \r\n217 | \r\n8969 | \r\n
| 7 | \r\n738 | \r\n33058 | \r\n
| 8 | \r\n2465 | \r\n114149 | \r\n
| 9 | \r\n7646 | \r\n360508 | \r\n
| 10 | \r\n19641 | \r\n930588 | \r\n
| 11 | \r\n28475 | \r\n1350852 | \r\n
| 12 | \r\n16547 | \r\n782536 | \r\n
| 13 | \r\n1976 | \r\n90280 | \r\n
| 14 | \r\n10 | \r\n276 | \r\n
| 15 | \r\n0 | \r\n0 | \r\n
| TOTALS | \r\n77802 | \r\n3674160 | \r\n
I\'ve been composing my messages in a word processor and then saving in HTML. The editor I used generates a lot of header info to format tables which this editor chokes on. Here\'s what I get with a different word processor. This OK?
\r\n
\r\n
| \r\n\r\n\r\n Shell \r\n\r\n | \r\n \r\n\r\n Classes \r\n\r\n | \r\n\r\n \r\n\r\n Elements \r\n\r\n | \r\n
| \r\n 0 \r\n\r\n | \r\n \r\n 1 \r\n\r\n | \r\n \r\n 1 \r\n\r\n | \r\n\r\n
| \r\n 1 \r\n\r\n | \r\n \r\n 1 \r\n\r\n | \r\n \r\n 4 \r\n\r\n | \r\n
| \r\n 2 \r\n\r\n | \r\n \r\n 3 \r\n\r\n | \r\n \r\n 10 \r\n\r\n | \r\n\r\n
| \r\n 3 \r\n\r\n | \r\n \r\n 6 \r\n\r\n | \r\n \r\n 24 \r\n\r\n | \r\n
| \r\n 4 \r\n\r\n | \r\n \r\n 15 \r\n\r\n | \r\n \r\n 58 \r\n\r\n | \r\n\r\n
| \r\n 5 \r\n\r\n | \r\n \r\n 35 \r\n\r\n | \r\n \r\n 140 \r\n\r\n | \r\n
| \r\n 6 \r\n\r\n | \r\n \r\n 85 \r\n\r\n | \r\n \r\n 338 \r\n\r\n | \r\n\r\n
| \r\n 7 \r\n\r\n | \r\n \r\n 204 \r\n\r\n | \r\n \r\n 816 \r\n\r\n | \r\n
| \r\n 8 \r\n\r\n | \r\n \r\n 493 \r\n\r\n | \r\n \r\n 1970 \r\n\r\n | \r\n\r\n
| \r\n 9 \r\n\r\n | \r\n \r\n 1189 \r\n\r\n | \r\n \r\n 4756 \r\n\r\n | \r\n
| \r\n 10 \r\n\r\n | \r\n \r\n 2863 \r\n\r\n | \r\n \r\n 11448 \r\n\r\n | \r\n\r\n
| \r\n 11 \r\n\r\n | \r\n \r\n 6862 \r\n\r\n | \r\n \r\n 27448 \r\n\r\n | \r\n
| \r\n 12 \r\n\r\n | \r\n \r\n 16324 \r\n\r\n | \r\n \r\n 65260 \r\n\r\n | \r\n\r\n
| \r\n 13 \r\n\r\n | \r\n \r\n 38550 \r\n\r\n | \r\n \r\n 154192 \r\n\r\n | \r\n
| \r\n 14 \r\n\r\n | \r\n \r\n 90192 \r\n\r\n | \r\n \r\n 360692 \r\n\r\n | \r\n\r\n
| \r\n 15 \r\n\r\n | \r\n \r\n 206898 \r\n\r\n | \r\n \r\n 827540 \r\n\r\n | \r\n
| \r\n 16 \r\n\r\n | \r\n \r\n 462893 \r\n\r\n | \r\n \r\n 1851345 \r\n\r\n | \r\n\r\n
| \r\n 17 \r\n\r\n | \r\n \r\n 992268 \r\n\r\n | \r\n \r\n 3968840 \r\n\r\n | \r\n
| \r\n 18 \r\n\r\n | \r\n \r\n 1973209 \r\n\r\n | \r\n \r\n 7891990 \r\n\r\n | \r\n\r\n
| \r\n TOTALS \r\n\r\n | \r\n \r\n 3792091 \r\n\r\n | \r\n \r\n 15166872 \r\n\r\n | \r\n
\r\n\r\n
In the context of my program, a group state is encoded using one byte per cubelet with I don’t know how much overhead as each state is wrapped as an objective C class. Not the most memory efficient way of doing it certainly.
\r\n
\r\nHow would one encode a group element as a single integer? Something like N modulo 120 for the corner position permutation, ( N / 120 ) modulo 3 for corner #1 twist , etc?
Had a look at cube-mail-13. Interesting to see symmetry discussed in a different context. As a chemist all my formal exposure to group theory was in connection with point group symmetry. W group? Heck, that\'s C2v. Same symmetry as a water molecule.
','74.137.194.164',1181267985,0,0,'2.1/','a:1:{i:0;i:0;}'),(344,341,87,23,'You don\'t actually code each','You don\'t actually code each group element as a single integer, exactly. Rather, you create a bijection between the group elements and the numbers from 1 to n (or sometimes from 0 to n-1), where n is the order of the group. The way I would create a bijection for S3 (for example) would be\r\n\r\n\r\n0: (0 1 2)\r\n1: (0 2 1)\r\n2: (1 0 2)\r\n3: (1 2 0)\r\n4: (2 0 1)\r\n5: (2 1 0)\r\n\r\n\r\nHere, I have shown the bijection in tabular form. An actual bijection in a program for a much larger group than S3 would involve some multiplying and dividing and some mixed base arithmetic.\r\n\r\n
\r\nI think most people use the Sims algorithm instead, which creates a similar (but not identical) bijection. However, the bijection induced by the Sims algorithm does not place the permuations in lexicographic order, and I prefer lexicographic order.\r\n
\r\n\r\nThe bijection for S3 (or for any Sn) is "extremely symmetrical", or one might even say "completely symmetrical". Cube groups are not quite as symmetrical as Sn. As examples of this "lack of complete symmetry", bijections for cube groups must explicitly (or implicitly via the Sims algorithm) take into account such things as preservation of total twist, preservation of total flip, and preservation of parity between corners and edges.\r\n
\r\n\r\nBut the bottom line with this idea is that you don\'t really store a bunch of positions in memory. In fact, your program typically never has more than one position stored in memory at a time. Instead, it stores the distance from Start associated with each position - often at one byte per position. And the table of lengths is indexed via the bijection between positions and the numbers from 1 to n (or from 0 to n-1).\r\n
\r\n\r\nThings get a