3x3x3 simulator in 745 bytes of javascript

[Kirjava]

(I also have a fail attempt here, I cannot understand why it fails to work... can any js gurus enlighten me? I'm probably forgetting some basic js concept...)

Because the return value of s.chatCodeAt is stored in c and is not a reference to the function.

 

[bundat]

Weird, if I try to alert out c, I get a "native code" output that makes me think I have the proper function reference.

If I try something like:

javascript:c="abcde".charCodeAt;for(i=0;i<5;i++)alert(i+":"+c(i))

Firefox 3.6 and IE8 both give: 91, 111, 98, 106, 101 (instead of 97-101)
Chrome just errors off with "Uncaught TypeError: String.prototype.charCodeAt called on null or undefined"
Latest Firefox also errors off with "TypeError: can't convert undefined to object"

I guess charCodeAt is actually a static method (in String), but behaves like a member method (by accessing "this")... if that makes sense?
So c doesn't manage to retain a reference to "this" (s)... I think, I'm not really sure.

Well, just ignore me, back to the topic of the tiny 3x3 sim.

 

[Kirjava]

never again

 

[Stefan]

never again

I wish you had turned the microphone on (not for key press sounds but for all the cursing I assume took place).

 

[Renslay]

I would do this:
1) Do a SIM scramble
2) Re-create the scramble on a real cube
3) Following the real cube, solve the SIM

Would it be considered as cheating?

 

[Stefan]

Btw, why don't we support let's say R, U and y instead? I think that would make it easier to use *and* save bytes.

 

[Kirjava]

I wish you had turned the microphone on (not for key press sounds but for all the cursing I assume took place).

I recorded it at work and don't have a microphone here.

Would it be considered as cheating?

I think it would make it harder, so no

Btw, why don't we support let's say R, U and y instead? I think that would make it easier to use *and* save bytes.

It'd be smaller at least - D moves would be a lot of keypresses

 

[Renslay]

It'd be smaller at least - D moves would be a lot of keypresses

But it's not hard to avoid D moves during the solving. Have to use a bit different algorithms.

 

[Stefan]

It'd be smaller at least - D moves would be a lot of keypresses

Pfft, who needs D moves. D moves are gay.

Supporting {R, U, D, y} instead of what we have now wouldn't add many bytes and make this thing fairly convenient. Or {R, U, F, y}. Or {L, R, F, B, U, D} actually. At some point, defining the keyCodes and their effects as a map should also become shorter than those repeated "q==XY?" tests.

Maybe we should have a standard, some kind of reasonable minimum functionality requirements for this game.

 

[Kirjava]

Supporting {R, U, D, y} instead of what we have now wouldn't add many bytes and make this thing fairly convenient.

I don't know, I think the point is minimalism - adding D to the movegroup is bloat.

Maybe we should have a standard, some kind of minimum functionality requirements for this game.

Yeah, I was thinking about that when it came to scrambling.

I mean, as long as you can simulate a full cube and it's solvable with some kind of scramble functionality - why would we need anything else?

 

[Stefan]

I don't know, I think the point is minimalism - adding D to the movegroup is bloat.

Three moves is bloat already. Remember [thread=19751]the entire cube is 2-gen![/thread]

 

[Kirjava]

Three moves is bloat already. Remember [thread=19751]the entire cube is 2-gen![/thread]

haha, now solving a sim like *that* would be impressive

 

[Stefan]

haha, now solving a sim like *that* would be impressive

Depending on which two algs you use, it might actually be very simple, just cumbersome because repetitive. You can pretty much solve one piece at a time, independently of the others. Similar to old pochmann for BLD, and I described it a bit here: http://groups.yahoo.com/neo/groups/speedsolvingrubikscube/conversations/topics/13973?l=1

Also, [post=655002]Bruce said[/post] that <x,Uz> suffices, even for "the group consisting of all supercube positions in all 24 orientations of the cube". Not sure if something even simpler (like <Rw,y> maybe?) suffices for the normal cube group, too lazy to check now...

Unfortunately, these kind of "moves" aren't just a bunch of 4-cycles anymore, so would require a different encoding/handling for us here.

 

[Kirjava]

Depending on which two algs you use, it might actually be very simple, just cumbersome because repetitive. You can pretty much solve one piece at a time, independently of the others. Similar to old pochmann for BLD, and I described it a bit here: http://groups.yahoo.com/neo/groups/speedsolvingrubikscube/conversations/topics/13973?l=1

There's also this, but it probably uses more space.

Also if we put it all on one line you can save two bytes of the '\n' char and then we can save four by using document.documentElement instead of document.getElementById('a'). Then we can stop using HTML entirely (possibly?).

 

[Stefan]

I think with so many people involved, we need some better kind of version control and merging now

Anyway... I forked your http://jsfiddle.net/c8uNB/13/ and got it to 411 bytes by using "h" as the storage and only *writing* to the document: http://jsfiddle.net/SH5UX/1/

Has the disadvantage of not showing anything before the first move. If you don't like that, pay six bytes for ;r("") at the end (or similar).

 

[Stefan]

Save two more by going backwards through s (changes the direction of the turns, easy to fix if desired):

for(j=0;j++<s.length
becomes
for(j=s.length;j--

Save one more by updating the document more often than necessary (this will break my ;r("") fix, though):
for(j=s.length;j--;document.getElementById('a').innerHTML=h=g.join(""))

 

[Stefan]

- Use onkeyup instead of onkeydown.
- Since we don't have one-click-scramble functionality anymore anyway, we might as well just scramble ourselves rather than use Math.random. Just hack away on the entire keyboard.
- No need for separate r and d functions, one can do all the work.

=> 339

 

[Kirjava]

wow

it's now less than half the size of the original

 

[Stefan]

teamwork ftw

Edit: This btw doesn't use {R,U,y} yet, which should shave off another 32 bytes from one of the effect strings. Due to all the encoding, I'm just not sure which ones. Thanks, Obama!

 

[Kirjava]

307

{R,U,y}

edit: can save 6 bytes by moving to one line