I'd like to build a reverse guess-game. (The player has a number in his mind, and the program tries to guess the number. You have three buttons. One button for a smaller tip, one for a bigger and one for the correct.) My app is generating the numbers on keypress, but the problem, that it doesn't remember my buttons I pressed. So for example the program tips number 50. I click "Smaller" button, it generates a smaller number, for example 35. I click "Bigger" button, and it can generate 80 or 90, even if I pressed "Smaller" for 50. How could I make the program "remember" the choices? Thank you :) Best regards!Sorry if I'm unclear, but I'm beginner.
This is my onclick:public void lowerClick(View v) {
tip = randomGenerator.nextInt(( highest + 1 ) - lowest ) + lowest;
textTip.setText(Integer.toString(tip));
{
The only problem is how I am supposed to change the highest and lowest parts and if I have to add anything to the program. I hope It's clear now. :) And thank you for your cooperation and understanding.
Tip: In the future, you should post any code you already have to show effort and avoid downvotes. However, I'll interpret this post as a general algorithm question.
You'll want two variables:
High Range: The highest possible number the user can be thinking of.
Low Range: The lowest possible number the user can be thinking of.
If the program guesses 50 and the user clicks Smaller, set the high range to 50, as you know the number must be under 50 from that point on.
If the program guesses 35 next, and the user clicks Bigger, set the low range to 35.
Always guess only numbers between the low range and high range, updating at each step. It's probably best to guess the point halfway in between the high and low range to maximize your chances. This would be somewhat of a binary search approach for guessing a number.
Related
I try to use Dynamic Time Warping (DTW) to detect gestures performed with a smartphone by using the accelerometer sensor. I already implemented a simple DTW-algorithm.
So basicly I am comparing arrays of accelerometer-data (x,y,z) with DTW. The one array contains my predefiend gesture, the other should contain the measured values. My problem is, that the accelerometer-sensor measures continously new values and I don't know when to start the comparison with my predefined value-sequence.
I would need to know when the gesture starts and when it ends, but this might be different with different gestures. In my case all supported gestures start and end at the same point, but as far as I know I can't calculate the traveled distance from acceleration reliably.
So to sum things up: How would you determine the right time to compare my arrays using DTW?
Thanks in advance!
The answer is, you compare your predefined gesture to EVERY
subsequence.
You can do this in much faster than real time (see [a]).
You need to z-normalize EVERY subsequence, and z-normalize your predefined gesture.
So, by analogy, if you stream was.....
NOW IS THE WINTER OF OUR DISCONTENT, MADE GLORIOUS SUMMER..
And your predefined word was made, you can compare with every marked word beginning (denoted by white space)
DTW(MADE,NOW)
DTW(MADE,IS)
DTW(MADE,THE)
DTW(MADE,WINTER)
etc
In your case, you don’t have makers, you have this...
NOWISTHEWINTEROFOURDISCONTENTMADEGLORIOUSSUMMER..
So you just test every offset
DTW(MADE,NOWI)
DTW(MADE, OWIS)
DTW(MADE, WIST)
DTW(MADE, ISTH)
::
DTW(MADE, TMAD)
DTW(MADE, MADE) // Success!
eamonn
[a] https://www.youtube.com/watch?v=d_qLzMMuVQg
You want to apply DTW not only to a time-series, but to a continously evolving stream. Therefore you will have to use a sliding window of n recent data points.
This is exactly, what eamonn described in his second example. His target pattern consists of 4 events (M,A,D,E) and therefore he uses a sliding window with length of 4.
Yet in this case, he makes the assumption, that the data stream contains no distortions, such as (M,A,A,D,E). The advantage of DTW is that it allows these kind of distortions and yet recognizes the distorted target pattern as a match. In your case, distortions in time are likely to happen. I assume that you want equal gestures performed either slow or fast as the same gesture.
Thus, the length of the sliding window must be higher than the length of the target pattern (to be able to detect a slow target gesture). This is computationally expensive.
Finally, my point is: I want to recommed you this paper
Spring algorithm by Sakurai, Faloutsos and Yamamuro.
They optimized the DTW algorithm for datastreams. You will no longer need more than n*n computations per incoming event but only n. It basically is DTW but cutting down all unneccesary computations and only taking the best possible alignment of the template onto the stream into account.
p.s. most of what I know about time-series and pattern matching, I learned by reading what Eamonn Keogh provided. Thanks a lot, Mr. Keogh.
To assume that we have 9 points. Each one can only be visited by once. The path, such as from the upper left corner to bottom right corner, is also allowed. Can anyone provide an algorithm to calculate the longest path for a screen lock pattern?
You need to provide distance metrics first.
Let's assume the following:
-Horizontal or vertical move can be long 1 for one step or 2 for two steps.
-Diagonally you will have length 1.41 for one step (Square root of 2, pythagorean theorem) or 2.83 for two steps (Square root of 8).
-Like a knight in chess you will have length 2.24 (Square root of 5)
So now you need to find just the maximum sum of this possible steps.
If you go with "Best first search" as mentioned above, it will be troublesome because the longest path does not choose alwayst the first best option.
For the following graph:
123
456
789
One option is 519467382, which would have length about 17.7
So maybe it is safer to try calculating all options as mentioned, but you can also keep in mind that because of the symmetry you need to calculate the lengths just for starting nodes 1, 2 and 5. The other nodes would give the same results, so no need for calculations....
It is similar to the travelling salesman problem (TSP), but instead of the shortest path you look for the longest one, and the path is not closed.
For the 9 points case I wouldn't be afraid of just trying all possible paths since there are just 9! = 362880 of them. And this number could potentially be reduced since 3 by 3 regular grid is highly symmetrical.
Another approach (since the path is not closed) could be doing a best-first search from a node with "best" being the one that has the longest path so far. You'll do this from each node remembering the longest path of them all. But this is just a quick thought and I have no proof this would actually work.
I calculated manually and I got the longest one to be 561943728 which has a length of 17.76 (take distance between two nearest dots to be 1 unit). If anyone can beat this then show your pattern!
Basically a TSP problem with a bit of modification that disallow stepping over points that hasn't been visited.
3x3 can be easily brute-forced. For slightly larger problems, the dynamic programming algorithm for TSP modified also works in {O(2^n*n^2)} time.
https://repl.it/#farteryhr/AndroidLockscreen#index.js
3x3: 17.779271744364845
591643728
573461928
591827346
537281946
573829164
519283764
537649182
519467382
4x4: 45.679014611640504 (0123456789abcdef)
92d6c3875e1f4b0a
68793c2d5e1f4b0a
92d6c3875b4f1e0a
68793c2d5b4f1e0a
a1e5f0b46d2c7839
5b4a0f1e6d2c7839
a1e5f0b4687c2d39
5b4a0f1e687c2d39
a4b5f0e19783d2c6
5e1a0f4b9783d2c6
a4b5f0e192d387c6
5e1a0f4b92d387c6
9786c3d2a4b0e1f5
6d293c78a4b0e1f5
9786c3d2a1e0b4f5
6d293c78a1e0b4f5
5x5: 91.8712723085273 (0123456789abcdefghijklmno)
ci6o0j5dbea9f8g4k3m1n7l2h
cg8k4f9bdae5j6i0o1m3l7n2h
ci6o0n1h7m2l3g8k4fe5jb9ad
c8g4k3l7h2m1n6i0o5ef9bjad
cg8k4l3h7m2n1i6o0ja9fd5eb
c6i0o1n7h2m3l8g4k9aj5dfeb
c8g4k9fdbeaj5i6o0n2l3h1m7
c6i0o5jbdaef9g8k4l2n1h3m7
The longest path would be 567 348 192
which is about 18.428
There are atleast 8 such patterns, one other is 567 381 932 (traverse length 18.428). Put a mirror image around those patterns and you get 4 patterns from one such pattern.
I need to generate objects for my little character to jump over. I have the artwork for these obsticles and my character can jump and I have a scrolling background.
How can I spawn my artwork for my obsticles on my x axis with spacing inbetween them?
Can anyone provide me with some sample code or atleast try and point me in the right direction?
Many Thanks,
James
Yes. You can. You want to use some sort of loop that generates them:
2 options you can use:
local function frameHandler()
if should_I_make_object() then
createObstacle()
end
end
Runtime:addEventListener("enterFrame", frameHandler)
this approach will create new objects according to frame rate. IE, lets
you create objects every 100 frames lets say. This will make levels play the
same (have the same number of obstacles) on different devices that have varied frame-rate
Option 2:
local function createObstacle()
--your_create_obstacle_code()
if game_is_still_playing() then
timer.performWithDelay(object_spawn_delay, createObstacle)
end
end
This option will create a new object every object_spawn_delay milliseconds.
This is easy to code, and is a nice solution when you need things to happen on
a time-dependent interval. But you do need code to decide if the game is still playing.
Also, be aware that if the game ends, there might still be a lingering callback to
createObstacle() that can create nasty bugs. Make sure to do proper cleanup when
the level / game ends and be aware this callback may be an issue.
I am trying to develop a keyboard for Android and I don't understand the background theories / algorithms about how to implement prediction of words by swiping (tracing) them on the keyboard as they were implemented in Swype, SwiftKeys and Android Built-in Keyboard.
Any document or example is appreciated.
We can break down the input process into more manageable chunks.
User places their finger on/near a starting letter.
User drags finger over/near X more letters.
User releases finger on/near the final letter.
The result of this is some jumble of letters where the order and proximity are the most important indicators of the actual word they were trying to enter. So now, the task is to take this sorted list of letters and find the closest matches in our dictionary.
The simple, brute-force approach here would be to query the database for words by dropping letters. For example, "DSRTYUIOKNBVFRE" could legitimately contain "DRY", I", "DO", "RUN", "SUN", "SON", "STOVE", "DRIVE", "STOKE", and probably a few dozen or so others. Suddenly, we've already reduced the search space to a few dozen words from a dictionary of thousands.
But we can do better than that. We know the user probably started near the correct letter and ended near the correct letter, so words like "DRY", "I", "DO", "RUN" and "SON" are unlikely to be correct, as they miss out lots of letters at the start and/or end of the input. So we can refine the list to the final three that I found: "STOVE", "DRIVE" and "STOKE" (and maybe a dozen more)
Assuming we're also weighing letters based on how close the user's finger went to them, we could further refine this list and then present them to the user in order.
Obviously I've skipped over the tricky details here - like converting the jumble of "DSRTYUIOKNBVFRE" into a list of possible words, and performing matching based on the input and the found strings. But I hope I've given an overview of how such keyboards work (and I'm sure they're now much more advanced than my description).
I have some suggestions.
Firstly, take a look at AnySoftKeyboard source code. This is basic but full-featured with text prediction and dictionaries. The code is clean and would make a good platform for extensions. Check out the Suggest, WordComposer and BinaryDictionary classes for functionality relating to word prediction. It has a dictionary with word frequency which tells you how frequently a word is found in 'real life'.
Secondly for the swipe algorithm. What you know for sure when a user swipes is what characters they started and finished on. This is a great start for prediction. I played with Swype a bit and it seems to always respect the start and end character.
In between the start and end characters, you have the ones the swipe passed over. These are possible characters to fill in the blanks. Now you can start taking guesses by making combinations of those chars and checking the dictionary for likely words. You'd always start your guess with the starting character, fill in some of the candidates from the swipe, and end with the finishing character. Show the user the best (highest frequency) matches from the dictionary.
That could be a lot of combinations to try, say 2^(n-2) where n is the number of characters under the swipe. So I'd suggest using a 'greedy' search and successively add characters from the start, keeping them if they match words in the dictionary otherwise discard them. Some refinements to this approach are probably necessary.
Another source of information you can use is when the swipe slows or changes direction on a particular character. You can detect this by calculating the speed (or acceleration) of the touch gesture. Points where the speed is low (or high deceleration) are likely to be characters the user wants.
So as an example, someone has swiped 'the'. They started on t, changed direction on h, and finished on e. These are your known points. Then you start guessing: the, tyhe, thge, thgfe, and so on and pick the words from the dictionary with the highest frequency count, which is obviously 'the' in this case.
Taking that algorithm and combining it with the prediction built into AnySoftKeyboard should yield something that works.
Hope that helps... tell us if you build it!
Prediction of words algo will go something like this.
you can provide your own static dictionary in the apk. when user installs it you can start with providing the word prediction after installation and first use.
To improve user experience you can have an algorithm to find the frequent words the user type.
and considering standard english(us) keyboard as an example you can see the proximity to the letter key which swipes user have done and show the suggestions accordingly.
ie. if user want to type(swipe) the word "SUN" , he starts swiping from the letter S and continues to Y instead of U and lastly to N. so you can use the PROXIMITY on the letter Y to find nearest set of letters. which are T, G, H, J, and U that suggest. words STN, SGN, SJN, SHN, SUN. so you can display SUN or TYPE - "SUN" in the textbox. OR if the user have used "SGN" or "SVN" more frequently you can have suggestion "SGN", "SUN" to the user and let the user to select the right word.
Going broad. Using sentences to Predict words
Continuing the same example of the word "SUN"
If the sentence user want to type is
I will commit on SVN tonight
so you can have the context of the sentence around the word (like the word commit etc..) SVN and correct the miss-typed(miss-swiped) S-Y-N to SVN directly.
or if the user wants to type a sentence
The SUN will rise in north today
you can apply the same thing according to the sentence context (like the word rise etc..) and let the S-Y-N mistake auto-correct to SUN.
Note :
This is my idea of designing the algorithm. If I have to implement the same thing I will use an Algorithm like this.
I am developing an OpenGL Android Game and I am right now dealing with the User Input.
I have two main ideas for implementing it. The two of them I think that they work perfectly but I do not know which one is "better" (in performance/speed).
The basics are that there are several "buttons" drawn in Opengl (such as four arrow keys, action button...) on some specific positions around the screen. These buttons do not change of place during gameplay.
FIRST IDEA
My first implementation was to create a 2D-matrix with references to each button. Something like:
InputObject matrix = new InputObject[Width_of_screen][Height_of_screen]
At the loading stage each button inserts in the Matrix its references for each pixel where they appear.
So each time the user touches the screen I can look directly on the matrix which button he has clicked (with e.getX() and e.getY()).
Pros: "Fast" to know which button to call.
Cons: (At common screens) 800*480 ~ 300K references, with 80% of them being null (But memory heap already taken)
SECOND IDEA
My second plan is to make an ArrayList of the Input Objects and ask each one if its theirs. Something like:
for(InputObject ob : TheArrayList){
if (ob.for_him(e.getX(),e.getY())){
ob.do_it();
break; //They cannot overlap
}
}
Pros: Less heap space taken (no null references at all...)
Cons: Have to detect for each object if its for itself, so they need to do comparisons on for_him method. Taking more CPU time.
With these said, which one may be the best idea for Android Phones (and other Smartphones) due to having not much processor time for user input.
If there is a third and best approach please I would love to know about it.
Thanks in advance.