Omnimaga
Calculator Community => Other Calc-Related Projects and Ideas => TI Z80 => Topic started by: Dapianokid on September 25, 2013, 05:34:01 pm
-
I have a very engaging, involved series of big and difficult to answer questions aimed at programming and cubing veterans, or anybody else who feels qualified to help out. (This may turn into an in-depth discussion holding multiple streams of conversation at once, beware! If you tl;dr often, this isn't the place for you.)
What would it take to write a Rubik's cube solving application/program for the Ti-83-84 series? I'm betting that the best platform to write it for is the Ti-84+CSE, mostly becuase that's what everybody is interested in right now and it has the newest operating system and a color screen in case there is a graphical component to this program.
Also, I'd like to challenge Omnimaga with the task of writing a program that can solve any cube state with an optimal solution path withing the course of a reasonable amount of time. It should probably take no longer than 4 hours to solve any one state.
I want to hear your thoughts on it, like what a cube-state culd look like in memory, algorithms or sequences stored as data, or how to maybe come up with a tiny, compressed structure for representing any cube state with a maximum of, say, 8 bytes. Who's up for it?
-
I don't really have the time right now to think about how you would actually go about this, but I would think that trying to represent the cube state compactly would be a big mistake.
The key issue with a program like this is going to be speed. You might run into memory problems, but, I think more realistically speed is the primary issue.
With that in mind, I think you should try to figure out how you are going to actually solve the cube, and then pick the data structure that allows you to run the simulation the fastest. It would be a little silly if 75% of your calculation time was spent compressing and decompressing the cube states ;D Besides, there are only actually 22 blocks that you can move. Representing each one as a byte would only be 22 bytes per cube.
-
I don't really have the time right now to think about how you would actually go about this, but I would think that trying to represent the cube state compactly would be a big mistake.
The key issue with a program like this is going to be speed. You might run into memory problems, but, I think more realistically speed is the primary issue.
With that in mind, I think you should try to figure out how you are going to actually solve the cube, and then pick the data structure that allows you to run the simulation the fastest. It would be a little silly if 75% of your calculation time was spent compressing and decompressing the cube states ;D Besides, there are only actually 22 blocks that you can move. Representing each one as a byte would only be 22 bytes per cube.
I don't actually have the time to help either but as thepenguin said with speed, I have heard that the Ti-84+CSE version is extremely slow. (Correct me if im wrong) So i'm assuming that would not be the best choice?
-
I don't really have the time right now to think about how you would actually go about this, but I would think that trying to represent the cube state compactly would be a big mistake.
The key issue with a program like this is going to be speed. You might run into memory problems, but, I think more realistically speed is the primary issue.
With that in mind, I think you should try to figure out how you are going to actually solve the cube, and then pick the data structure that allows you to run the simulation the fastest. It would be a little silly if 75% of your calculation time was spent compressing and decompressing the cube states ;D Besides, there are only actually 22 blocks that you can move. Representing each one as a byte would only be 22 bytes per cube.
I don't actually have the time to help either but as thepenguin said with speed, I have heard that the Ti-84+CSE version is extremely slow. (Correct me if im wrong) So i'm assuming that would not be the best choice?
The CSE is only slow when it draws something on the screen. But calculations don't take longer on a color screen than on a monochrome screen (as long as you don't draw anything).
-
Hm, maybe you should have brought this up after the omnimaga contest :P
-
I don't really have the time right now to think about how you would actually go about this, but I would think that trying to represent the cube state compactly would be a big mistake.
The key issue with a program like this is going to be speed. You might run into memory problems, but, I think more realistically speed is the primary issue.
With that in mind, I think you should try to figure out how you are going to actually solve the cube, and then pick the data structure that allows you to run the simulation the fastest. It would be a little silly if 75% of your calculation time was spent compressing and decompressing the cube states ;D Besides, there are only actually 22 blocks that you can move. Representing each one as a byte would only be 22 bytes per cube.
I don't actually have the time to help either but as thepenguin said with speed, I have heard that the Ti-84+CSE version is extremely slow. (Correct me if im wrong) So i'm assuming that would not be the best choice?
The CSE is only slow when it draws something on the screen. But calculations don't take longer on a color screen than on a monochrome screen (as long as you don't draw anything).
You learn something new everyday! Thanks!
-
I didn't intend on this being part of the contest, in fact, I intended it not being part of the contest. I also don't olike hosting contests. I'm basically asking help with a project that isn't as long-term/sketchy in terms of my desire to bring it to completion.
First off, recursive search algorithms would be incredibly slow on the calculator past any more than, say, 3 distinct HTM turns. HTM means that turning a face twice still counts as one turn. Hopefully whatever system I use to solve the cube will be capable of a half turn just as fast as it will be a quarter turn.
I don't want a memory-eating program, as I'm hoping to be able to run it on the 83+BE.
I'll be looking at the most commonly used algorithms. maybe I only want it to solve withint 20 moves.
-
I didn't intend on this being part of the contest, in fact, I intended it not being part of the contest. I also don't olike hosting contests. I'm basically asking help with a project that isn't as long-term/sketchy in terms of my desire to bring it to completion.
[...]
I thought that, but i mean that seeking for non-contest coding help while a contest is running will make it more unlikley to find somebody due to already the contest taking up so much time. (do i make sence?)
-
You do make sense, my friend.
*sigh* I'll wait patiently for you people to be less busy :P
-
(do i make sence?)
No, but you spelled sense wrong. :P
As for the CSE, it depends how you draw stuff. In some cases the speed isn't that bad (see Calcuzap and Tunnel, for example).