I am playing around with http://boost-experimental.github.io/msm-lite/tutorial/index.html (tag is for boost-msm because there is not tag for msm-lite but similar question applies) and I have a question wrt designing state machines with many possible inputs.
Imagine you are modelling elevator. Beside obvious states like moving, stopped, door_open, door_closed I wonder how to model button pressed(that is a number from -2 to 39) since it is not feasible to have that many events(42 just for every button pressed).
I guess if you design a floor selection with 42 buttons you would probably not map them each to a single input, but make a matrix (nobody will put 42 buttons on top of each other, would one?). Then of course you would not model each row an column but only two so you can show the sequential polling of each row column. Maybe you could also use "intelligent" buttons today that have a microchip which sends some "I have been pressed" information a serial line. Or you introduce a voice recognition.
Having listed those few examples, I tend to close this question as simply too broad.
You can use guard conditions on transitions. They look like [currentFloor != requested floor]. Perhaps a better way is to model events like upper floor selected, lower floor selected, current floor selected. That collapses 42 buttons into three categories rather neatly.
Related
I'm writing a GUI in python, and using tkinter. I'm having trouble settling on an approach and need guidance.
Background: there's a server (not a webserver) that wants to present a lot of information to users, and let them edit some of it. It needs to send down information that a (relatvely) dumb python client uses to fill the window. Read only fields are Labels. The fields are generally single line Entry widgets, but some are multiline Text. There are some buttons, checkboxes and dropdowns. Asynchronously, the server can also update widgets, add them and remove them. In some cases, there are tables presented, to which the user needs to be able to add and remove rows.
The real problem is, the layout is dense and chaotic. The first row might contain 3 dropdown fields. The next might be 20 short Labels. The next might be a single long Entry field, and then I might want two tables (of different lengths) side by side,and then etc.. Based on user input of external factors, widgets, rows or entire tables might have to be dyamically added, or vanish.
I considered Grid, but it's unusable. A row with a single, long entry widgit in it, makes the first column wide and thereby pushes 12 of the 13 columns in the next row right off the window.
I considered Place, but this app will run on 3 different operating systems and users will be able to select their own fonts, so I'll never get the positions right. If there was some way to ask a widget how big it was, I'd happily use that to compute my own layouts in pixels, but it's apparently impossible to ask the size of a widget until AFTER it's been laid out by a geometry manager, which of course is too late.
So what I think I'm left with is Pack, where each row is its own frame, and some of those rows have tables (grids) in them. But I'm concerned that that means lots and lots of frames to render, and some of the users are on old, slow hardware. Plus... it looks just plain complex.
Am I missing a better way? Grid would be fine if I could convince it to stop trying to make columns line up. Place would be crunchy, but ok, if I could get the size of each widget in advance. Is placing within a lot of frames really the best I have?
Short answer, there's no better way; and the frame count isn't high enough to cause performance problems; so generating a frame per row is what works.
So, a bit of explanation to preface the question. In variants of Open Face Chinese poker, you are dealt one and one card, which are to be placed into three different rows, and the goal is to make each row increasingly better, and of course getting the best hands possible. A difference from normal poker is that the top row only contains three cards, so three of a kind is the best possible hand you can get there. In a variant of this called Pineapple, which is what I'm working on a bot for, you are dealt three and three cards after the initial 5, and you discard one of those three cards each round.
Now, there's a special rule called Fantasyland, which means that if you get a pair of queens or better in the top row, and still manage to get successively better hands in the middle and top row, your next round becomes a Fantasyland round. This is a round where are dealt 15 cards at the same time, and are free to construct the best three rows possible (rows of 3, 5, and 5 cards, and discarding 2 of them). Each row yields a certain number of points (royalties, as they're called) depending on which hand is constructed, and each successive row needs better and better hands to yield the same amount of points.
Trying to optimize solutions for this seemed like a natural starting point, and one of the most interesting parts as well, so I started working on it. My first attempt, which is also where I'm stuck, was to use Simulated Annealing to do local search optimization. The energy/evaluation function is the amount of points, and at first I tried a move/neighbor function of simply swapping two cards at random, having first places them as they were drawn. This worked decently, managing to get a mean of around 6 points per hand, which isn't bad, but I often noticed that I could spot better solutions by swapping more than one pair of cards at the same time. Thus, I changed the move/neighbor function to swapping several pairs of cards at once, and also tried swapping a random amount of pairs between 1 and 3 through 5, which managed to yield slightly better results, but still I often spot better solutions by simply taking a look.
If anyone is reading this and understands the problem, any idea on how to better optimize this search? Should I use a different move/neighbor function, different Annealing parameters, or perhaps a different local search method, or even some kind of non-local search? All ideas are welcome and deeply appreciated.
You haven't indicated a performance requirement, so I'll assume that this should work quickly enough to be usable in a game with human players. It can't take an hour to find the solution, but you don't need it in a millisecond, either.
I'm wondering of simulated annealing is the right method. This might be an opportunity for brute force.
One can make a very fast algorithm for evaluating poker hands. Consider an encoding of the cards where 13 bits encode the card value and 4 bits encode the suit. OR together the cards in the hand and you can quickly identify pairs, triples, straights, and flushes.
At first glance, there would seem to be 15! (13,076,743,680,000) possible positions for all the cards which are dealt, but there are other symmetries and restrictions that reduce the meaningful combinations and limit the space that must be explored.
One important constraint is that the bottom row must have a higher score than the middle row and that the middle row must have a higher score than the top row.
There are 3003 sets of bottom cards, COMBINATIONS(15 cards, 5 at a time) = (15!)/(5!(15-5)!) = 3003. For each set of possible bottom cards, there are COMBINATIONS(10 cards, 5 at a time) = (10!)/(5!(10-5!)) = 252 sets of middle cards. The top row has COMBINATIONS(5 cards, 3 at a time) = (5!)/(3!*(5-3)!) = 10. With no further optimization, a brute force approach would require evaluating 3003*252*10 = 7567560 positions. I suspect that this can be evaluated within an acceptable response time.
A further optimization uses the constraint that each row must be worth less than the row below. If the middle row is worth more than the bottom row, the top row can be ignored by pruning the tree at that point, which removes a factor of 10 for those cases.
Also, since the bottom row must be work more than the middle and top rows, there may be some minimum score the bottom row must achieve before it is worth trying middle rows. Rejecting a bottom row prunes 2520 cases from the tree.
I understand that there is a way to use simulated annealing for estimating solutions for discrete problems. My use of simulated annealing has been limited to continuous problems with edge constraints. I don't have a good intuition for how to apply SA to discrete problems. Many discrete problems lend themselves to an exhaustive search, provided the search space can be trimmed by exploiting symmetries and constraints in the particular problem.
I'd love to know the solution you choose and your results.
Is there any body of evidence that we could reference to help determine whether a person is using a device (smartphone/tablet) with their left hand or right hand?
My hunch is that you may be able to use accelerometer data to detect a slight tilt, perhaps only while the user is manipulating some sort of on screen input.
The answer I'm looking for would state something like, "research shows that 90% of right handed users that utilize an input mechanism tilt their phone an average of 5° while inputting data, while 90% of left handed users utilizing an input mechanism have their phone tilted an average of -5°".
Having this data, one would be able to read accelerometer data and be able to make informed decisions regarding placement of on screen items that might otherwise be in the way for left handed users or right handed users.
You can definitely do this but if it were me, I'd try a less complicated approach. First you need to recognize that not any specific approach will yield 100% accurate results - they will be guesses but hopefully highly probable ones. With that said, I'd explore the simple-to-capture data points of basic touch events. You can leverage these data points and pull x/y axis on start/end touch:
touchStart: Triggers when the user makes contact with the touch
surface and creates a touch point inside the element the event is
bound to.
touchEnd: Triggers when the user removes a touch point from the
surface.
Here's one way to do it - it could be reasoned that if a user is left handed, they will use their left thumb to scroll up/down on the page. Now, based on the way the thumb rotates, swiping up will naturally cause the arch of the swipe to move outwards. In the case of touch events, if the touchStart X is greater than touchEnd X, you could deduce they are left handed. The opposite could be true with a right handed person - for a swipe up, if the touchStart X is less than touchEnd X, you could deduce they are right handed. See here:
Here's one reference on getting started with touch events. Good luck!
http://www.javascriptkit.com/javatutors/touchevents.shtml
There are multiple approaches and papers discussing this topic. However, most of them are written between 2012-2016. After doing some research myself I came across a fairly new article that makes use of deep learning.
What sparked my interest is the fact that they do not rely on a swipe direction, speed or position but rather on the capacitive image each finger creates during a touch.
Highly recommend reading the full paper: http://huyle.de/wp-content/papercite-data/pdf/le2019investigating.pdf
Whats even better, the data set together with Python 3.6 scripts to preprocess the data as well as train and test the model described in the paper are released under the MIT license. They also provide the trained models and the software to
run the models on Android.
Git repo: https://github.com/interactionlab/CapFingerId
I decided to write a small program that solves TicTacToe in order to try out the effect of some pruning techniques on a trivial game. The full game tree using minimax to solve it only ends up with 549,946 possible games. With alpha-beta pruning, the number of states required to evaluate was reduced to 18,297. Then I applied a transposition table that brings the number down to 2,592. Now I want to see how low that number can go.
The next enhancement I want to apply is a strategic reduction. The basic idea is to combine states that have equivalent strategic value. For instance, on the first move, if X plays first, there is nothing strategically different (assuming your opponent plays optimally) about choosing one corner instead of another. In the same situation, the same is true of the center of the walls of the board, and the center is also significant. By reducing to significant states only, you end up with only 3 states for evaluation on the first move instead of 9. This technique should be very useful since it prunes states near the top of the game tree. This idea came from the GameShrink method created by a group at CMU, only I am trying to avoid writing the general form, and just doing what is needed to apply the technique to TicTacToe.
In order to achieve this, I modified my hash function (for the transposition table) to enumerate all strategically equivalent positions (using rotation and flipping functions), and to only return the lowest of the values for each board. Unfortunately now my program thinks X can force a win in 5 moves from an empty board when going first. After a long debugging session, it became apparent to me the program was always returning the move for the lowest strategically significant move (I store the last move in the transposition table as part of my state). Is there a better way I can go about adding this feature, or a simple method for determining the correct move applicable to the current situation with what I have already done?
My gut feeling is that you are using too big of a hammer to attack this problem. Each of the 9 spots can only have one of two labels: X or O or empty. You have then at most 3^9 = 19,683 unique boards. Since there are 3 equivalent reflections for every board, you really only have 3^9 / 4 ~ 5k boards. You can reduce this by throwing out invalid boards (if they have a row of X's AND a row of O's simultaneously).
So with a compact representation, you would need less than 10kb of memory to enumerate everything. I would evaluate and store the entire game graph in memory.
We can label every single board with its true minimax value, by computing the minimax values bottom up instead of top down (as in your tree search method). Here's a general outline: We compute the minimax values for all unique boards and label them all first, before the game starts. To make the minimax move, you simply look at the boards succeeding your current state, and pick the move with the best minimax value.
Here's how to perform the initial labeling. Generate all valid unique boards, throwing out reflections. Now we start labeling the boards with the most moves (9), and iterating down to the boards with least moves (0). Label any endgame boards with wins, losses, and draws. For any non-endgame boards where it's X's turn to move: 1) if there exists a successor board that's a win for X, label this board a win; 2) if in successor boards there are no wins but there exists a draw, then label this board a draw; 3) if in successor boards there are no wins and no draws then label this board a loss. The logic is similar when labeling for O's turn.
As far as implementation goes, because of the small size of the state space I would code the "if there exists" logic just as a simple loop over all 5k states. But if you really wanted to tweak this for asymptotic running time, you would construct a directed graph of which board states lead to which other board states, and perform the minimax labeling by traversing in the reverse direction of the edges.
Out of curiosity, I wrote a program to build a full transposition table to play the game without any additional logic. Taking the 8 symmetries into account, and assuming computer (X) starts and plays deterministic, then only 49 table entries are needed!
1 entry for empty board
5 entries for 2 pieces
21 entries for 4 pieces
18 entries for 6 pieces
4 entries for 8 pieces
You're on the right track when you're thinking about reflections and rotations. However, you're applying it to the wrong place. Don't add it to your transposition table or your transposition table code -- put it inside the move generation function, to eliminate logically equivalent states from the get-go.
Keep your transposition table and associated code as small and as efficient as possible.
You need to return the (reverse) transposition along with the lowest value position. That way you can apply the reverse transposition to the prospective moves in order to get the next position.
Why do you need to make the transposition table mutable? The best move does not depend on the history.
There is a lot that can be said about this, but I will just give one tip here which will reduce your tree size: Matt Ginsberg developed a method called Partition Search which does equivalency reductions on the board. It worked well in Bridge, and he uses tic-tac-toe as an example.
You may want to try to solve tic-tac-toe using monte-carlo simulation. If one (or both) of the players is a machine player, it could simply use the following steps (this idea comes from one of the mini-projects in the coursera course Principles of Computing 1 which is a part of the Specialization Fundamentals of Computing, taught by RICE university.):
Each of the machine players should use a Monte Carlo simulation to choose the next move from a given TicTacToe board position. The general idea is to play a collection of games with random moves starting from the position, and then use the results of these games to compute a good move.
When a paritular machine player wins one of these random games, it wants to favor the squares in which it played (in hope of choosing a winning move) and avoid the squares in which the opponent played. Conversely, when it loses one of these random games, it wants to favor the squares in which the opponent played (to block its opponent) and avoid the squares in which it played.
In short, squares in which the winning player played in these random games should be favored over squares in which the losing player played. Both the players in this case will be the machine players.
The following animation shows a game played between 2 machine players (that ended in a tie), using 10 MC trials at each board state to determine the next move.
It shows how each of the machine players learns to play the game just by using Monte-Carlo Simulation with 10 trials (a small number of trials) at every state of the board, the scores shown at the right bottom of each grid square are used by each of the players at their corresponding turns, to choose its next move (the brighter cells represent better moves for the current player, as per the simulation results).
Here is my blog on this for more details.
I'm wondering about how the NES displays its graphical muscle. I've researched stuff online and read through it, but I'm wondering about one last thing: Nametables.
Basically, from what I've read, each 8x8 block in a NES nametable points to a location in the pattern table, which holds graphic memory. In addition, the nametable also has an attribute table which sets a certain color palette for each 16x16 block. They're linked up together like this:
(assuming 16 8x8 blocks)
Nametable, with A B C D = pointers to sprite data:
ABBB
CDCC
DDDD
DDDD
Attribute table, with 1 2 3 = pointers to color palette data, with < referencing value to the left, ^ above, and ' to the left and above:
1<2<
^'^'
3<3<
^'^'
So, in the example above, the blocks would be colored as so
1A 1B 2B 2B
1C 1D 2C 2C
3D 3D 3D 3D
3D 3D 3D 3D
Now, if I have this on a fixed screen - it works great! Because the NES resolution is 256x240 pixels. Now, how do these tables get adjusted for scrolling?
Because Nametable 0 can scroll into Nametable 1, and if you keep scrolling Nametable 0 will wrap around again. That I get. But what I don't get is how to scroll the attribute table wraps around as well. From what I've read online, the 16x16 blocks it assigns attributes for will cause color distortions on the edge tiles of the screen (as seen when you scroll left to right and vice-versa in SMB3).
The concern I have is that I understand how to scroll the nametables, but how do you scroll the attribute table? For intsance, if I have a green block on the left side of the screen, moving the screen to right should in theory cause the tiles to the right to be green as well until they move more into frame, to which they'll revert to their normal colors.
~~~~EDIT:
I do want to point out that I know about the scanlines, X and Y. This thought just ran through my mind.
Let's say I'm at scanline Y of 10. That means I'm reading 10 values into my nametables, horizontally. That would mean my first column is off of the screen, as it only has pixel width of 8. However, the color attribute stays, since it has width of 16.
Assuming the color attribute for the entire column is green, would I be correct in assuming that to the user, the first 6 pixels on the left of the screen would be colored green, and the rightmost 10 on the screen should be green as well?
So, would I be correct in my assumption that according to the screen, the left?
This site I'm sure you are already very, very familiar with. I will preface this by saying I never got to program for the NES, but I am very experienced with all the Gameboy hardware that was ever released and the NES shares many, ahh quirks with the GB/DMG. I going to bet that you either need to do one of a few things:
Don't scroll the attribute table. Make sure that your levels all have similiar color blocks along the direction you are moving. I'd guess that many first generation games did this.
Go ahead and allow limited attribute scrolling - just make sure that the areas where the changes are occuring are either partially color shared or sparce enough that the change isn't going to be noticable.
Get out your old skool atari 2600 timer and time a write to register $2006 in the end of HBlank update to get the color swap you need done, wait a few tics, then revert during the HBlank return period so that the left edge of the next line isn't affected. I have a feeling this is the solution used most often, but without a really good emulator and patience, it will be a pain in the butt. It will also eat a bit into your overall CPU usage as you have to wait around in interrupts on multiple scan lines to get your effect done.
I wish I had a more concrete answer for you, but this hopefully helps a bit. Thanks goodness the GB/DMG had a slightly more advanced scrolling system. :)
Both Super Mario Bros. 3 and Kirby's Adventure display coloring artifacts on the edge of the screen when you scroll. I believe both games set the bit that blanks the left 8 pixels of the screen, so 0-8 pixels will be affected on any one frame.
If I remember correctly, Kirby's Adventure always tries to put the color-glitched columns on the side of the screen that is scrolling off to make it less noticeable. I don't think these artifacts are preventable without switching to vertical mirroring, which introduces difficulties of its own.
Disclaimer: it's been like five years since I wrote any NES code.
Each nametable has its own attribute table, so there should be no graphical artifacts when scrolling from one nametable to another. The type of color glitching you are referring to is really only an issue if your game scrolls both vertically and horizontally. You only have two nametables, so scrolling both ways requires you to cannibalize the visible screen. There are various solutions to this problem, a great summary of which can be found in this nesdev post:
http://nesdev.parodius.com/bbs/viewtopic.php?p=58509#58509
This site may be of some help.
http://www.games4nintendo.com/nes/faq.php#4
(Search for "What's up with $2005/2006?" and begin reading around that area.)
It basically looks like its impossible to get it pixel perfect, however those are going to be the bits you're probably going to need to look into.
Wish I could be more help.
Each nametable has its own attribute table. If you limit your game world to just two screens, you'll only need to write the nametables and attribute tables once. The hard part comes when you try to make worlds larger than two screens. Super Mario Bros. 1 did this by scrolling to the right, wrapping around as necessary, and rendering the level one column of blocks at a time (16 pixels) just before that column came into view. I don't know how one would code this efficiently (keep in mind you only have a millisecond of vblank time).