You and Brandon already discussed the point I wanted to make here. "+FaceIV" is neither a face nor an edge. "CornersideII" is totally different to the first Cornerside. Exactly. Each of the piece types can be represented by a subgroup of Oh, the symmetry group of the hexahedron. "+FaceIV" obeys a different subgroup of Oh than "+Face" or "Edge" does. Therefore they are different piece types. "+FaceIV" has 12 instances but that doesn't mean much because a group can have many different subgroups with identical size. In my preliminary system for classifying virtual pieces I labeled this piece type with "Uz".

BTW:
Does anybody know a good description of the subgroups of Oh quickly understandable by Average-Joe?
I made one for myself, but that is not really comprehensible.

The number of different piece types in "traditional" hexahedral puzzles is rather low: Core, Face, Corner, Edge, Wings, T-Faces and ObLiques. Please note that X-Faces are geometrically identical to Wings. When Circle-variants and strange interconnected layers are considered, I expect that you will find a piece type for all subgroups of Oh.

At least in theory everything is easier in the dodecahedral world because Ih (the symmetry group of the dodecahedron) has far less subgroups as Oh.

You noticed, that there are still some deviations.
The restrictions orientations in the Skewb (or Skewb Diamond) is another one I want to explain more. In fact all puzzles with this axis system tend to be "halved", as all pieces here either have a halved number of orientations or fall into (at least) two orbits. Furthermore in this axis system it is possible to let one halve of the pieces vanish: Please compare 5.1.2 and 5.1.3
This is not that surprising because here we are dealing with Th, the symmetry group of the tetrahedron, which is itself a subgroup of Oh.
When aiming at a consistent classification scheme we have to make one choice here:
1. Option: We introduce Th as the third symmetry group and define corner, edge, face, etc... for this group too.
2. Option: We treat this puzzles and its pieces as part of the hexahedral family and accept, that there are deviations.
I vote for option 2 because it makes our life easier when we want to deal with the puzzles of 3.4.X. In that case the deviations vanish.
Yes. This piece type deviates strongly from the theory. But imaging a hybrid puzzle with two different axis systems. Maybe the deviations vanish there too.
Sadly I can't view 3.3.30 (your only example for Type 5c) right now. But from your second image I would say: This is the same order as 3.3.1 because of the same number of logical layers per axis.
Yes. I think that too.

Today I gathered some stats from the ranking page, and computed some numbers like how many moves per second I am using, or how many moves per puzzle I'm using, with or without macro moves. The attached file contains the stats for the current top 20 puzzle solvers. Please go find yourself in it!

Since everything is from the current ranking page, if you have solved a puzzle many times, the effort is not reflected in the table, unfortunately. Also, if you cannot make it to the top 50 list, it's not possible to get the time/move count. Although the stats are crude, we can really see different styles from different solvers.

Here are some facts:

--I took advantage from macro the most: solving 64% of the puzzles using macro, 85% of my twists are done by macro.
--In terms of the number of puzzles solved without help of macro, Agamemnon and Julian tie on 237. I wonder who will lead in the near future.
--Julian spent the most time playing Gelatinbrain. The accumulated time is about 20 days (excluding preparation and re-solving).
--On average, Michael Gottlieb, of course, spent the least amount of time on each puzzle he solved: 9.8 min.
--Doug Cube, always focusing on the harder puzzles, spent the most time per puzzle: over 2 hours.
--Michael Gottlieb clicked the mouse about 0.55 time per second, the fastest (about one move every other second).
--On the opposite side, Doug Cube and Julian think for 13~14 seconds per move.
--Although Daniel Kwan is leading the fewest move list, GuiltyBystander gets the fewest move per puzzle.
--Although the numbers of total moves per puzzle vary a lot, from 200 to 2000, the numbers of manual moves (by clicking mouse) are relatively close, varying from 200 to 600 (most of us between 300-500).

Note: the last column, macro moves per puzzle, is the ratio between the macro moves and the number of those puzzles involving macro, but not all the puzzles.

Any more stats one wants to see?

Dear schuma, that was a good idea!
I would like to have an overview with news i.e. when I go on the rankings page, the latest changes would be displayed.

with regard to my 3.3.n classification:
It looks like there are a few suggestions for my table. To not impede the discussion I will leave the table as it is.

3.3.30 is a creative puzzle, which has a beautiful simple design:

Thanks for this -- interesting! I haven't had much time for solving this year, so I've been feeling like I've been neglecting GB compared to some other solvers here... but now I feel better seeing that I've spent the most time on solves over the last few years! I guess around 2-3 days of my total solve time was spent taking rest breaks or, in the case of 1.1.17, sleeping overnight.

I'd like to see a stat for each solver's average moves/record ratio, for example, if someone averages 50% more moves than the least moves record for each puzzle, their ratio would be 1.5. You could do the same thing with the time taken: an average time/record ratio. These ratios should make efficient solvers movewise and/or timewise stand out, even if they don't have so many records. It probably makes sense to exclude puzzles with only one solver from these stats.

GuiltyBystander has a bunch of stats about solvers, their move count factor and time factor compared to the best for each puzzle, the number of times they have stollen a record versus had a record stollen, etc. Hopefully he'll chime in

I've been keeping some stats too for a while, here's some other interesting metrics.

Most solves in a day:

Stolen 1sts. These are solves that were 1st when they were made but aren't anymore. I'm counting move and time records as 2 separate records that can be stolen.

lol. This is clearly an artifact that I go for easy puzzles and have been avoiding the harder ones that require more moves.
When comparing moves/times I use a relative metric. For each solve, I score them as solve_moves/record_solve_moves. So if the record is 100 moves, and you did it in 174, it's 1.74 points. When comparing people, I just look at their average.

Top people for times are Michael Gottlieb (1.1), fusion (2.16), and schuma (2.85).
Top people for moves are Daniel Kwan (1.08), haru (1.1), and Michael Gottlieb (1.47). With this measurement, I'm at a distant 9th with 2.53. (or 13th if you compare to people with only 10 solves).

*edit* This is what Julian is asking for, but I haven't filtered out puzzles with only one solver. If you do, it would only affect schuma and his scores would shoot up to 3.25 / 3.55 for times / moves.

*edit2* @ bmenrigh. Yep, I'm writing this up as you were posting

Interesting! Thank you for sharing these stats! The ranking page is full of data (~2MB) and there are so many interesting ways to look at them.

I'm sure this has been asked before, but when I load the page on my mac, it says "The publisher cannot be verified by a trusted source. Code will be treated as unsigned. Name: org.jdesktop.applet.uti.JNLPAppletLauncher. sun.security.ValidatorException: PKIX path validation failed: java.security.cert.CertPathValidatorException: Untrusted certificate: CN=Java Media APIs, OU=Java signed Extensions, OU=Corporate Object Signing, 0=Sun Microsystems Inc"
It then loads the page with everything on it and working... Except the cube!
Also, I am running Safari, Chrome, Opera, and Firefox! They all get the same message!
EDIT: Forgot to mention, running Mountain Lion on a MacBookPro

See this thread.

The short answer is that due to a very poor interaction between Java and Browsers it is better to download a local copy of the program and run it rather than trying to launch it from a web browser. That thread has the details for how to do that. Hit me up in IRC if you need help.

Hi, I have read Andreas' last post carefully. He has raised some interesting points about symmetrie-groups. That has tempted me myself to deal a bit with symmetry groups. It has not to do with what he said, but I had an interesting idea:
If you would take any symmetry group such as the cube-wings as axes system for a puzzle, that would perhaps result in new puzzles.
To display this axis-system to me, I have adapted the sphere applet by Jaap a little bit. Here is a screen-shot showing a cube-wings-axis-system:
Now I let the circles intersect a bit:
You can see, only 360° rotations are possible, so the idea was wrong/useless for building new puzzles.

Interesting idea. It's true that only 360° rotations are possible for non-jumbling moves but this puzzle as pictured jumbles. If you made the depth of cuts big enough so that there is more interaction between grips and added some unbandaging (where possible) I think you'd have a serious puzzle.

Hi Brandon, thank you for your reply. I have tried to outline unbandaging and would like to ask, whether it is what you meant.

How about making the marked distances equal? I tried to make a picture of it in SketchUp, and not surprisingly failed.


Clearly the cuts are misaligned, but you hopefully get the idea.

Hmm this isn't what I was thinking.

First some labels:


What I want to be able to do is at least A, B', A', B where each of these is a jumbling turn by about 59.34°.

After A:


Then after B':


Now to follow up with A' you need to add this cut to each wedge:


But you'd actually probably end up adding this cut to each side of the circles which would really open up a ton of jumbling:



EDIT:
Oops, I labeled the routine I wanted to do as A B' A B but I really mean the [1,1] jumbling commutator A B' A' B

For what it's worth, the unbandaging that I'm suggesting is exactly like the typical Helicopter Cube unbandaging.

I found the idea very well, and tried to implement it:I still need a little time to understand your approach. It is very interesting.

I am glad that I could inspire another fruitful (sub)thread).

Here is another unbandaging try similar to Brandons:

Still I can't imagine how that would give a puzzle, but maybe it would.

Again on the subject of the cube-wings axle set with equal distances:
Without unbandaging (wich Brandon proposed),
I asked me the question, would this give a (jumbling) puzzle?maybe.

I created an image with POV-Ray for illustrative purposes, (i was so glad about it, when it was finished, because I used POV-Ray for the first time and it turned out to be pretty easy). let me show it to you. I'm not sure about it. Is it possible to include it into gelatinbrain's virtual polyhedra?

Looks great. Are you willing to post the source to your POV-Ray model?

I still think that without unbandaging the scrambleability of this puzzle is very limited.

Yeah, I can:
I had to try it.

I've just updated both java and win32 versions.
Non new puzzles. I only disabled the "submit" button.
The scores sent by old programs arrive me.
But the scoreboard updating is temporarilly suspended.
Please keep the certificates until I find a new solution.

Hey Gelatinbrain, I didn't notice your mention of C++ source code but I just saw your site with the link

I had to fix two typeos in your Qt project file ("qt/mainpanelayout.cpp" -> "qt/mainpanellayout.cpp" and "qt/gramewindow.h" -> "qt/framewindow.h") but after that it compiled cleanly

I see you're using anti-aliasing to draw the puzzle. It looks way better than the Java version.

The only "bugs" I can spot right now are a slightly different color scheme and the MagicPolyhedra binary uses 100% of the CPU at all times. Perhaps you need to yield() or sleep() in the event loop?

Just your zzz/* code is 90,000 lines of code. Have you been maintaining both a Java and C++ version all along? I'm amazed that you've been able to keep two branches mostly in sync with each other.

I have some ideas / a proposal for hosting and a scoreboard but I'll follow up with a PM about that a bit later.

Thank you for testing, Brandon.


I don't do anything special. Sounds a good news anyway.

The event loop is not in my code. It's included in the Qt framework. But I will see what I can do.
Do you think that's why my computer roars like a vacuum cleaner when I run my program?
Maybe it's another problem...


In the future I'm planning to keep only the sources on my server, and leave
anyone free to use them.
This way I can concentrate only on programming.


For those who want to compile and run on Mac,
here is how to create the project for Mac. Simply copying project files may not work.
Good luck!

gelatinbrain brought new puzzles to us. Thanks!

I found a bug in the latest .jar:

After I execute a macro, the "move" textbox will not display any moves I made by clicking any more. Can anyone reproduce this bug?

Gelatinbrain, thanks for four new puzzles. I just want to let you know that I'm with you: I've solved all the new 2.9.* puzzles up to 2.9.16, and have kept all the certificate codes. When will the scoreboard be updated? Do you need any help?

By the way, the bug of move textbox is still not completely fixed. Thanks anyway!

I'm not sure when I can restart the service.
But I can do an exception for you. Send your certificates and I will process them manually.
Otherwise you can help me by posting your method here.

This doesn't reproduce on my machine. Maybe it's a Mac-only problem.

I'm not sure if this is the right place to ask, but I have a question about the Magic Polyhedra / Gelatin Brain applet. How do you use macros? I cannot find any tutorials for it and Google was no help. Also, why is the Scrambles box always blank?

You can perform a macro via copy and paste.

As you perform moves you'll see them get listed in the "Moves" box. You can select them and copy them out. For example:


You can then paste those moves into the Input box and hit the "<<<<<" button to apply them again. The input box will ignore the /*comment*/ stuff.

The input box also accepts [] grouping characters so you can do [U, F]. Also, it accepts []xN so you can do [U, F]x104 to apply the 2-move sequence 104 times.

I wrote a quick and dirty script at http://www.brandonenright.net/cgi-bin/gb_util.pl for processing move sequences. If you want to do a lot of solving or share move sequences with others it should save you some time.

Thanks, bmenrigh.

Is there a good way to handle slice moves? The output appears to be the same for a slice or outer turn. For example, on the 4x4x4, both r and R turns produce an output of R in the Moves list. Very strange.

You're welcome I know my username can be cumbersome but go ahead and call me Brandon.

Gelatinbrain uses a slice bitmask. The outer turning portion is bit 1, the first slice is bit 2, next is bit 4, etc.

So if you want to turn the R slice you'd use R&2. If you want to turn the outer face and inner slice, you can do R&3, etc. Here is a contrived example for 3.1.5: [R'&2, U'&2, R&2, U&2, R', U'&2, R'&2, U&2, R&3]

Personally I think the slice bitmask is superior to R and r being different because it is more flexible across a wide variety of puzzles. CaSe SensITIvitY tends to be an annoying property for free-form input.

Today gelatinbrain gave us a very special puzzle, 9.1.1. I took a brief look at it and I don't know what that is.... It seems like dragging it not only changes the orientation of the whole puzzle, but also does some permutation to it.

Does anyone have any idea about what's going on?

Based on the name I think it's a 3D version of this group:
http://en.wikipedia.org/wiki/PSL(2,7)

I spent 20 minutes trying to understand how it's interconnected but I still have questions. The group is non-abelian so I'm not sure if every move sequence has a short inverse. I think I found any easy 3-cycle but after performing it I couldn't find a view that showed me all three pieces it moved.

EDIT:
I did more testing. It seems like the dual of a 3D solid where each face has 7 sides. Because there isn't any normal solid with 7-gon faces Gelatinbrain has folded in two of the of the triangles around each vertex to make it look like an Icosahedron.

There are 4 folded regions and each of these is missing a triangle so to show that triangle for each region there is a tetrahedron in the center made up of the 4 missing triangles.

A pure [3,1] 3-cycle is trivial: [B, A, B', V, B, A', B', V']

I would describe this puzzle as being similar to a face-turning dodecahedron. Only instead of 12 faces there are 24(?) and instead of each face being modulo 5 they are modulo 7. The difficulty in solving is going to be predominately from the view and piece finding rather than some of the other hard twisty puzzle properties.

There is probably a MagicTile equivalent to this puzzle.

This is the closed form of klein's quartic mapped on a tetrahedron.
Analogue of platonic solid with 24 heptagonal faces and 56 vertices.
I've got the idea from this site.
I think the animation on this page is the only way to map the klein's quartic onto 3D without deforming the connectivity.

I mapped all vertices to equilateral triangles. So there are inevitably broken edges.
If you map the klein's quartic on hyperbolic plane, the pieces close to the rim become too small. And it's difficult to change the orientation of the puzzle.
If may method is not the best, I think it's a good compromise.


On the opposite of each tetrahedral vertex, there's a small triangle.




Later I will post another image to explain the notation.

Brandon and gelatinbrain, thank you for your explanation. Now I understand it.

In MagicTile there's a face-turning {7,3}, which has centers, edges and corners just like 3x3x3 or Megaminx. Here, 9.1.1 is the corner-only version of the face-turning {7,3}. The algorithms are similar to those for 2x2x2 or kilominx.

Of course the visualizations are quite different: the one in MagicTile is drawn on a hyperbolic plane and the one in GB is folded in Euclidean space. I agree to gelatinbrain that without hyperbolic panning, the puzzle in hyperbolic plane is pretty hard to deal with. This was the case in the first edition of MagicTile. Thanks for hard work of Roice Nelson, the second version of MagicTile has hyperbolic panning. So it is pretty convenient now.

I played 9.1.1 for a while, and I found that piece finding was harder than in MagicTile. Many triangles are folded inside. Sometimes dragging can reveal them, but sometimes the destination is lost. Well, that is the challenge of this puzzle and I believe I'll swallow it someday.

Another thing is, ideally there should be 24 colors. But there are only eight colors on 9.1.1. I believe they are arranged in a way that no two triangles are identical (or even mirrored). But still, it's a bit tricky for piece finding.

Gelatinbrain, congratulations for making this version of Klein's quartic!! Don't make the next puzzles of this category too hard... I really can't find pieces....

I just solved the new puzzles Gelatinbrain added, 1.10.1, 1.11.* and 1.12.*. They are not very complicated, but some of them, that is, 1.11.2 and 1.11.3, show interesting orientation cases and parity issues. I enjoy solving them, and recommend them to everyone!

Gelatinbrain, nice job!