This is a math question - but really I'm looking for some vocabulary to help me google what I'm trying to do here. God bless you if you manage to read this and understand what I'm talking about.
I have some javascript code that looks at the frequency data from a song as it is playing and turns the data into 2 numbers. These numbers change several times per second depending on what is going on in the song.
One number (upperAvgFr) represents the 'loudness' of the values coming from the average upper frequencies, and the other (lowerAvgFr) represents the loudness coming from the average lower frequencies. I modulate these values so they stay between 0 and 1.
I'm then taking these 2 numbers and translating them into visual movement on a 3d object (the objects are just glowing squares simple squares with some symbols on them). I make them 'pulse' - growing larger and smaller or spinning, changing color - based on the values of the upper frequency and lower frequency number.
So... all that said, I'm finding myself wanting to know some math tricks to play with the distribution.
If I use the upperAvgFr as a multiplier on the height and width of the graphical pulsing square - it would be very small when the value is close to 0, and full size when it is close to 1.
My question is, what are these type of functions called (and where are they found) that can redistribute or transform the values in these distributions so that it is not as even anymore.
Maybe the higher values all get closer to 1, and the lower values stay the same. All of them may be "nudged up" a small amount, but less for the lower numbers, and more for the higher numbers.
That would be one instance of a transform that might be useful, another instance might do the same thing in the opposite direction, or pull them all closer to the middle, etc.
Best example that I can find that is "kinda" like what I want are easing functions where things accelerate and move in non-linear ways: https://konvajs.org/docs/tweens/All_Easings.html
What kind of function am I describing here? Where can I find libraries of these functions? I imagine they could come in handy with tweening and easing. I imagine there are some that give "pleasant" feeling distributions. Some might be "choppier". or "bouncier." What words am I looking for her?
Related
One of my friends proposed a problem where you have n number of buckets (a, b, c, ..., n), each with a certain percentage of your total balls. You are then given a breakdown of how many balls each bucket should have by the end of the problem. You are also supplied a machine that, in one move, can move unlimited balls from a singular bucket to another singular bucket (ex. 10 balls from bucket A to bucket C). What algorithm would you use to ensure you always have the least number of moves possible?
I got stumped by this. It looks like it could be solved using an extension of Euclid's algorithm, but I'm altogether unsure as to how I would solve this. I tested the obvious answer of trying to match the 2 largest/perfect problem buckets with each other but that doesn't work. Any pointers would be helpful.
Use A* on the graph of possible moves with the heuristic function: number of buckets different from their goal bucket divided by two. That is b/2 where b is the number of buckets which have the wrong amount in them.
A* is often thought of as a pathfinding algorithm for like routing units in an game, but it works on any graph that you can find an heuristic that never overestimates the distance to the target node. Most importantly, A* armed with such a heuristic will always find the shortest path. Borrowing from game theory, we can think of a graph, nodes connected by links, where each node is a possible distribution of balls among the buckets and each link represents a legal move the machine can make. Your starting node is the starting distribution of balls. Your target node is the target distribution of balls.
With this graph we could apply a breath-first search and the wait until we happen to visit the target node. This would give us a shortest set of moves from start distribution to target distribution, since it is a breath-first search. (This is more or less equivalent to Dijkstra's algorithm in this case because each move has the same cost (length) of 1 move)
However, we can do better. A* searches through a graph using a heuristic. Specifically, it is like the breath-first search except instead of next visiting an un-visited node nearest to the starting node, A* next visits an un-visited node which minimizes g(n) + h(n) where g(n) is the length from the unvisited node, n, to the starting node and h(n) is an heuristic for the distance from the unvisited node, n, to the goal. This means we spend less computational time hunting for the optimal path by going "away" from the goal as we check the obvious path to goal first. It has been mathematically proven that A* will give you the optimal path from your starting node to the goal node if you can find a heuristic that is admissible, meaning a heuristic that never overestimates the distance to goal. For example, in a video game, the length of a walkable path between two points is always greater or equal to the by-the-crow-flies distance. In spite of our graph not being a graph that represents physical space, we can still find an admissible heuristic.
A move can at best make 2 buckets have the correct number of balls, as a move can only effect two buckets at most. Thus, for example, if we count our buckets and see that 4 buckets have the wrong about of balls in them, then we know that at least 2 moves will be required. Quite possible more, but it can't be less than 2.
Lets make our heuristic be "the number of buckets which have the wrong number of balls divided by 2".
Our heuristic doesn't overestimate the number of moves required to get desired number of balls, since even the best kind of move where you match up happy pairs can happen for every move you only tie our heuristic. Our heuristic underestimates moves quite often but that is okay, the computation will just take longer but it won't get the wrong result, and the result plan for moves will still the shortest possible. Thus, our heuristic is admissible, meaning that it never overestimates the number of moves.
Therefore, A* with a heuristic of "the number of buckets which have the wrong number of balls divided by 2" will always find the shortest number of moves to reach the distribution.
Perhaps a better heuristic can be found, if so, then the search will go faster. This was merely the first heuristic I thought of.
I've deleted my previous answer. Have you considered the subset sum problem? I'm not sure if it will find the optimal solution for the overall problem, but here is the idea.
For each bucket, let the difference = (target number of balls) - (given number of balls). Let P be a set of positive differences and N be a set of absolute values of negative differences.
Choose the next maximum number from the two sets, and look for a minimum subset sum in the opposite set. If the subset is found, move the balls. Otherwise, look for the subset sum for the next maximum number from the sets.
After finishing looking for subsets, consider the remaining buckets. Move the balls between two of the remaining buckets from opposite sets. This will create a new difference for one of the buckets. It is possible that a new matching subset sum can be formed with the new difference. Search for the subset sum again using that newly formed difference. Repeat until all of the buckets have the target number of balls.
I'm not sure if always considering the largest buckets guarantees optimality. Let us know if you find the correct solution!
I read somewhere that javascript is handling whole numbers better than decimal etc.
Since I am working with SVG a lot I thought hmm SVG is about vectors so its coordinates system could be whatever we want.
Now I built this naive performance test here:
https://jsperf.com/svg-whole-numbers-or-not
Question - the test shows 50% faster processing for the case with whole numbers. Can someone explain if avoiding using non-whole numbers actually give any real benefit?
I basically want to know should I (even if the performance win is small) just by default avoid non-whole numbers when I work with SVG?
The speed difference is largely accounted for by the need to "anti-alias" stroke and fill operations by differentially shading pixels which are adjacent to a path that does not run between adjacent pixels.
While this can occur for horizontal lines, vertical lines and rectangles, it would not generally apply to diagonal lines, curves and arbitrary shapes.
Avoiding non integer values will not benefit general purpose svg drawings. It may speed up a sub class of drawings such as very simple flow diagrams that make use of horizontal and vertical joiners and boxes. Whether the care or editing to use whole number coordinates is worth the time saved is (imho) doubtful.
In my game a large map exists, and I am wondering if not drawing shapes (average 250+ at a time) when the player cant see them would make any difference in the game's performance.
Also, every frame I am checking the distance of the player to about 500+ other position vectors (used for enemies, food, bullet interactions), which takes a lot of square rooting. If I make a raw estimate just using the X and Y components combined, would that significantly boost game performance?
The only way to answer these questions is to try it and see what happens. You have to weigh the cost of calculating whether something is on the screen against the cost of drawing it. Again, you're going to have to measure both and decide for yourself.
As for measuring distance, you could try using the distance squared to avoid the square root.
Or you could try storing your objects in a data structure like a quadtree, which allow you to you only check the distance of nearby objects. Or putting it simpler: do you really need all 500 vectors active all of the time? Why not store them and only activate them when you need them?
But again, the only way to answer your question is to try it. We can't tell you whether this will vastly improve performance in your game. Only you can answer that, by trying things out. Good luck.
I want to find the text lines in a page of text (like from a book).
Sample image:
One of the problems is that I want to implement this in Javascript and this is the best computer vision library that I found:
http://inspirit.github.io/jsfeat/#imgproc
Therefore I am limited to the algorithms implemented in JSFeat (or another JS library).
I thought of doing feature detection on the page and then doing statistics on the plotted points to find the lines. I'm not sure that's a good idea or how this can be done.
For example this is the output of FAST when applied on that image.
It should work regardless of the font used. Also slight rotation tolerance would be even better.
Help much appreciated!
My approach would be to count the number of vertical edges on each horizontal scanline. Each letter will produce two or more edges.
First, use the sobel operator to calculate x derivative:
Now we have positive and negative edges, but we want to count them both as positive. So take the absolut value:
Now count the edges on each line. This can be done by summing the pixels up, or simply by scaling the image to a width of 1px, leaving the height unchanged. For easy viewing I've plotted the result:
Now you'll need to threshold this result somehow, or maybe find the maxima after running a blur on the 1px-width image. If the font size and the letters per line stay roughly the same, this is easy.
You may want to re-run on different rotations of the original image and then use the result with the highest contrast.
I'm having a problem with finding N positions in a grid based on a central point and a max range.
I have this grid, each coordinate in the grid can be either closed or open, I'm tying to, using an open coordinate, find all the open coordinates around the first that are valid and the walk range between then is equal or lower than the max walk range.
At first I tried a solution using A*, where I would select every coordinate in range, check if they were valid, if they were I would call A* from them to the center position and count the number of steps, if they were higher than my max range I would just remove the coordinate from my list. Of course, this is really is slow for ranges higher than 3, or grids with more than just a few coordinates.
Then I tried recursively searching for the coordinates, starting with the central one, expanding and recursively checking for the coordinates validness. That solution proved to be the most effective, except that in my code, each function call was rechecking coordinates that were already checked and returning repeated values. I thought I could just share the 'checked' list between the functions calls, but that just broke my code, since a call was checking a coordinate and closing it even if it still had child nodes but were technically not in range of their center (but were in range of the first center) it would close them and give some weird results.
Finally, my question is, how do I do that? Is my approach wrong? Is there a better way of doing it?
Thanks.
I've implemented something similar once. The simple recursive solution you proposed worked fine for small walk ranges, but execution time spun out of control for larger values ...
I improved this by implementing a variant of Dijkstra's algorithm, which keeps a list of visited nodes as you said. But instead of running a full path search for every coordinate in reach like you did with A*, do the first N iterations of the algorithm if N is your walk range (the gif on Wikipedia might help you understand what I mean). Your list of visited nodes will then be the reachable tiles you're looking for.
http://en.wikipedia.org/wiki/Dijkstra%27s_algorithm