Version: 3.5.1 (using KDE 4.6.2) OS: Linux If a move that is undo-able without the undo button is made (so that all the cards are in the exact same place as before) it shouldn't need to recalculate solve-ability. Solve-ability should be the same in both cases. Not only this, sometimes it recalculates it from 'Solver: Unable to determine if this game is winnable.' to other states, and back. It should stay at 'Solver: This game is winnable.' or 'Solver: This game cannot be won'. Also, if the game was solvable before hitting 'undo', or doing a move that is undo-able without the undo button, it'll be solvable after hitting 'undo', or manually undoing it, no need to recalculate, until another non-undo button move is made. (unless something is random, or this is based on ONLY the information the user has up to that point in the game <-feature request; keep both ways available, individually, or together. (2^2 choices), maybe even a hybrid way that calculates solve-ability knowing what was shown before the undo button was hit. (2^3 choices).) The results of solve-ability could be stored with undo history to further save processing time when doing an undo. If a solution is found after doing a move, the solve-ability history could be updated, to reflect this. After a solution is found for the current situation, all items in the current undo history should be marked as solvable, even if already marked as unknown. After a 'Solver: This game cannot be won' point all future moves/redos can be marked as 'no longer winnable' without added testing. Although, I suppose doing this way might affect the debugging of the solver in some way. Question: Are the cases where moves aren't undo-able in one move, but are undo-able with more than one move? Reproducible: Always Steps to Reproduce: Make a move that is undo-able without the undo button, it'll recalculate solve-ability, instead of just using last results, sometimes coming up with a different answer. Actual Results: It'll recalculate solve-ability, instead of using last results. Expected Results: It'll use the last results without having to recalculate resolvability. OS: Linux (x86_64) release 2.6.38-8-generic Compiler: cc
storing all positions and checking all the time if you had this before sounds overkill to me. So I close this as WONTFIX. And you're right, that we keep on solving even after having had a lost because we found a tons of bugs this way in the solver.
(let's just call moves that can be undone without the undo button, 'manually undo-able', to distinguish it from just hitting the undo button. And 'manually undo-able arrangements' as card arrangements that have manually a undo-able move that can go from one arrangement to the other arrangement and back. Feel free to help come up with a better names) "you're right, that we keep on solving even after having had a lost because we found a tons of bugs this way in the solver." This should be saved for a debugging mode. For regular use mode use mode you can do it like stated here... "storing all positions and checking all the time if you had this before", How about just comparing it to the LAST move? That should cover the most obvious cases. Win-ability is transitive for manually undo-able arrangements. If the first move is manually undo-able , and the second move also manually undo-able, etc... it'll be possible to manually go all the way back to anywhere between these manually undo-able arrangements. A 'winnable' or 'can not be won' on any of them means that these arrangements are all 'winnable' or 'can not be won', respectively. No need to reprocess on another manually undo-able move, or an 'undo button' move with a move that is manually undo-able. I'm sure checking to see if a move is manually undo-able back to the last position, and the looking at the previous arrangement's solve-ability state, takes a lot less time would take a lot less time than trying to re find out if it's solvable. For debugging you could have a separate mode that rechecks solve-ability after every move. Since the solver can't realize the win-ability is the same in undo-able arrangements and sometimes comes up with different answers for rather or not it's solvable or unknown, (switching from 'unknown' to 'winnable', or 'cannot be won' or vise-versa for these), the win-ability can be made 'sticky'. When a 'winnable' or 'cannot be won' arrangement appears, any manually undo-able arrangement is also 'winnable' or 'cannot be won'. Just find out if it is manually undo-able. For the 'history' aka 'undo', etc... It can be marked so that from a 'cannot be won' point all future moves/redos will cause the game to still be 'cannot be won' games, no extra win-ability testing needed, and once a 'winnable' shows up all points earlier in the history/undos in a game are 'winnable', no extra win-ability testing needed. This would save a lot of processing time when using the 'undo'/'redo' buttons. Above in chart form... When ___ is found ___ history items (including it's manually undo-able arrangements in history) are all ___ since ___ 'winnable', 'past', 'winnable', "it's possible to go from the previous positions to the current positions for this game and then go on to win." 'can not be won', 'future', 'can not be won', "if it were possible to win from a 'can not be won' position, it wouldn't be a 'can not be won' position." I suppose rather or not a move is manually undo-able to the last position as well as win-ability could be stored in the history, instead of recalculated when needed. Maybe we could call this feature 'stickiness of win-ability' to last position. It'll save processing time with manual undo-able moves, 'undo' when the current arrangement is 'winnable', 'redo' when in 'can not be won' arrangements. It'll also increase accuracy of win-ability in these cases. With only a slight increase in processing time, if no manually undo-able moves are made, and 'undo'/'redo' buttons are not used. two extra points for the undo history: 'winnable' point: point at which all items at and *before* in the history are 'winnable'., <= W 'can not be won' point: point at which all items at and *after* in the history are 'can not be won'., >= L 'unknown' goes in-between these two points., !<= W & !>= L - Idea list overview Using last state for moves that are manually undo-able. Processing 'undo button'/'manual undo' when in 'winnable' state. / Processing 'future moves'/'redo button' when in 'can not be won' state. Adding a debugging option for when you don't want to do the above.
Checking for "manual undos" seems silly. If the user knows that a move is going to be a manual-undo, why don't they just hit Undo? If they don't know, then they probably aren't expecting special behaviour. Adding extra code and further complicating the solver to speed up such a corner case hardly seems like an increase in efficiency. Since May 2010, KPat the solvability is stored in the undo history, so that particular request has been implemented. At that time, I experimented with propagating solvability backward through the history and unsolvability forward through the history. As you mention, it would theoretically reduce the time spent processing and supply the user with better information. The problem is that the solver isn't perfect; it produces both false positives and false negatives. Trying to extrapolate from false information only compounds the problem by increasing amount of false information. Maybe in the future, if the solver's reliability has been much improved, we could look into this again.
"Checking for "manual undos" seems silly. If the user knows that a move is going to be a manual-undo, why don't they just hit Undo?" The checking to see if a move is manually undo-able (to the last position) was to save time, instead rechecking solve-ability; If a move can be manually undone(aka the card can go back to where it was before the move without the undo button), then the solve-ability would be the same after the move as before the move. It's like the "propagating solvability backward through the history and unsolveability forward through the history" except without hitting the undo button. For simplicity, it can check if the moved card can move back to where the card was before the move. If it can then it can, then the previously calculated solve-ability(if available) could be used. Of course, you'll still have the problem of the solver not being perfect. "The problem is that the solver isn't perfect; it produces both false positives and false negatives. Trying to extrapolate from false information only compounds the problem by increasing amount of false information." [idea only, might not actually improve things] Maybe a more exact solve-ability could be used, even if it takes more time, so that solve-ability propagation would make since. Or make solve-ability propagation optional, and add a warning about accuracy* if enabled, and/or add an option to do it both ways, aka propagate for immediate answer*, and recalculate for more accurate answer. *If the solver is inaccurate it might have an item in the past that says unsolvable, and an item in the future that says solve-able, maybe this could turn into saying 'unknown'? or even a submit to developer case?
It still doesn't make sense to invest time here.