This question already has answers here:
finding all minimal spanning trees [duplicate]
(3 answers)
Closed 3 years ago.
I have a small graph (<30 edges) with many edges with only 3 possible lengths.
In order to get an optimal tree, I started to find the minimum spanning tree. But there is a strong probability that there are several solutions for this, and in this case, I want to get all the minimum spanning trees, in order to apply an other custom filter.
Let's start with an example:
ab = 3
bc = 3
ac = 2
ad = 3
cd = 1
Here, possible MSTs are ac, cd, ab and ac, cd, bc.
I started to find them with Kruskal, where we need to sort edges by length first.
I had the idea to find all possible sorted lists, then applying Kruskal for each of them. More precisely, I group edges by lengths, then I find all possible permutations for each group. For the example below, all possible sorted lists are:
ab, bc, ad, ac, cd
ab, ad, bc, ac, cd
bc, ab, ad, ac, cd
bc, ad, ab, ac, cd
ad, ab, bc, ac, cd
ad, bc, ab, ac, cd
It works. For this small graph.
But if I try this with a graph with 10 edges of same length, there is several millions of possible permutations, and applying Kruskal for each of them is not really optimized.
Any idea?
You can do in many possible way, you need to use Kruskal or prims algorithm and modify them, such that every time you find edges with the same weight you do a recursion and restart a new tree from the actual vertex.
Return all the possible MST it is not efficient, think to a fully connected graph that has all the edges with same weight. There will be `O(n^n) possible trees.
A lot of tree will have some equal part so you can find a better solution, but you still need to return them all and this is not efficient.
You can read this paper for more Algorithm for Enumerating All Spanning Trees of Undirected and Weighted Graphs or a python implementation
Related
I am writing some CUDA code for finding the 3 parameters of a circle (centre X,Y & radius) from many (m) measurements of positions around the perimeter.
As m > 3 I am (successfully) using Singular Value Decomposition (SVD) for this purpose (using the cuSolver library). Effectively I am solving m simulaneous equations with 3 unknowns.
However, not all of my perimeter positions are valid (say q of them), and so I have to go through my initial set of m measurements and remove the q invalid ones. This involves moving the size m data array from the card to the host, processing linearly to remove the q invalid entries and then re loading the smaller (m-q) array back onto the card...
My question is; if I were to set all terms on both sides of the q invalid equations to zero, could I just run the m equations (including the zeros) through my SVD analysis (without the data transfer etc) or would this cause other problems?
My instinct tells me that this is a bit like applying weights to the data but instinct and SVD are not terms that sit well together in my experience...
I am hesitant just to try this as I don't know if it will work in some cases and not in others...
I have tested the idea by inserting rows of zeros into my matrix. The solution that I am getting is not significantly affected by this.
So I am answering my own question with a non-rigorous Yes it is OK do do this.
If anybody has a more rigorous or more considered answer I would very much like to hear it.
Last month, a user called #jojek told me in a comment the following advice:
I can bet that given enough data, CNN on Mel energies will outperform MFCCs. You should try it. It makes more sense to do convolution on Mel spectrogram rather than on decorrelated coefficients.
Yes, I tried CNN on Mel-filterbank energies, and it outperformed MFCCs, but I still don't know the reason!
Although many tutorials, like this one by Tensorflow, encourage the use of MFCCs for such applications:
Because the human ear is more sensitive to some frequencies than others, it's been traditional in speech recognition to do further processing to this representation to turn it into a set of Mel-Frequency Cepstral Coefficients, or MFCCs for short.
Also, I want to know if Mel-Filterbank energies outperform MFCCs only with CNN, or this is also true with LSTM, DNN, ... etc. and I would appreciate it if you add a reference.
Update 1:
While my comment on #Nikolay's answer contains relevant details, I will add it here:
Correct me if I’m wrong, since applying DCT on the Mel-filterbank energies, in this case, is equivalent to IDFT, it seems to me that when we keep the 2-13 (inclusive) cepstral coefficients and discard the rest, is equivalent to a low-time liftering to isolate the vocal tract components, and drop the source components (which have e.g. the F0 spike).
So, why should I use all the 40 MFCCs since all I care about for the speech command recognition model is the vocal tract components?
Update 2
Another point of view (link) is:
Notice that only 12 of the 26 DCT coefficients are kept. This is because the higher DCT coefficients represent fast changes in the filterbank energies and it turns out that these fast changes actually degrade ASR performance, so we get a small improvement by dropping them.
References:
https://tspace.library.utoronto.ca/bitstream/1807/44123/1/Mohamed_Abdel-rahman_201406_PhD_thesis.pdf
The thing is that the MFCC is calculated from mel energies with simple matrix multiplication and reduction of dimension. That matrix multiplication doesn't affect anything since any other neural networks applies many other operations afterwards.
What is important is reduction of dimension where instead of 40 mel energies you take 13 mel coefficients dropping the rest. That reduces accuracy with CNN, DNN or whatever.
However, if you don't drop and still use 40 MFCCs you can get the same accuracy as for mel energy or even better accuracy.
So it doesn't matter MEL or MFCC, it matters how many coefficients do you keep in your features.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
What would be the most appropriate (naturally suited) way to represent the various chord progression (musical) rules in a data-structure such that each chord had a weighted set of options that it could progress to?
This data structure would be implemented in a procedural music generation program in a way that you could code: (language-agnostic pseudo-code)
Chord[7] songArray;
Chord first = new Chord(I); //set the first chord's value
songArray[0] = first;
for (i=0; i<7; i++){
Chord temp = songArray[i].next(); //select the following chord
songArray[i+1] = temp;
}
Note: In classical-type music, each chord in a given key can naturally progress to another chord following these rules:
----------------------
| Chord | Leads to |
|=======================
| I | any |
| ii | V, vii |
| iii | IV, vi |
| IV | ii, V, vii |
| V | vi |
| vi | ii, ii, IV, V|
| vii | I |
----------------------
The data structure would store the various progressions as weighted options. As an example, consider the IV chord in any given major key: IV can naturally progress to ii, V, or vii, but could also break the rules in progressing to any other chord. Breaking the rules would happen infrequently.
I have considered some sort of linked list/tree data structure, but it would hardly resemble any type of tree or list I've ever used -- additionally, I can't work out how to implement the weighting:
Another thought was to use JSON or something similar, but it seems to get redundant very quickly:
{
"I":{
"100%":{
"I",
"ii",
"iii",
"IV",
"V",
"vi",
"vii"
}
},
"ii":{
"80%":{
"V",
"vii"
},
"20%":{
"i",
"ii",
"iii",
"IV",
"vi"
}
},
// ...
}
Note: I am comfortable implementing this in a handful of languages, and at this point am NOT concerned with a specific language implementation, but a language-agnostic data-structure architecture.
A Markov Chain might be a good fit for this problem.
A Markov chain is a stochastic process where the progression to the next state is determined by the current state. So for a given interval from your table you would apply weights to the "Leads to" values and then determine randomly to which state to progress.
I'd expect you to have less than 100 chords, therefore if you use 32 bits to represent probability series (likely extreme overkill) you'd end up with a 100x100x4 (40000) byte array for a flat Markov matrix representation. Depending on the sparsity of the matrix (e.g. if you have 50 chords, but each one typically maps to 2 or 3 chords) for speed and less importantly space reasons you may want an array of arrays where each final array element is (chord ID, probability).
In either case, one of the key points here is that you should use a probability series, not a probability sequence. That is, instead of saying "this chord has a 10% chance, and this one has a 10% chance, and this one has a 80% chance) say "the first chord has a 10% chance, the first two chords have a 20% chance, and the first three chords have a 100% chance."
Here's why: When you go to select a random but weighted value, you can generate a number in a fixed range (for unsigned integers, 0 to 0xFFFFFFFF) and then perform a binary search through the chords rather than linear search. (Search for the element with least probability series value that is still greater than or equal to the number you generated.)
On the other hand, if you've only got a few following chords for each chord, a linear search would likely be faster than a binary search due to a tighter loop, and then all the probability series saves you calculating a simple running sum of the probability values.
If you don't require the most staggeringly amazing performance (and I suspect you don't -- for a computer there's just not that many chords in a piece of music) for this portion of your code, I'd honestly just stick to a flat representation of a Markov matrix -- easy to understand, easy to implement, reasonable execution speed.
Just as a fun aside, this sort of thing lends itself well to thinking about predictive coding -- a common methodology in data compression. You might consider an n-gram based algorithm (e.g. PPM) to achieve higher-order structure in your music generation without too much example material required. It's been working in data compression for years.
It sounds like you want some form of directed, weighted graph where the nodes are the chords and the edges are the progression options with edge weights being the progression's likelihood.
I suck at math, so I can't figure this out: how many combinations of k neighboring pixels are there in an image? Combinations of k pixels out of n * n total pixels in the image, but with the restriction that they must be neighbors, for each k from 2 to n * n. I need the sum for all values of k for a program that must take into account that many elements in a set that it's reasoning about.
Neighbors are 4-connected and do not wrap-around.
Once you get the number of distinct shapes for a blob of pixels of size k (here's a reference) then it comes down to two things:
How many ways on your image can you place this blob?
How many of these are the same so that you don't double-count (because of symmetries)?
Getting an exact answer is a huge computational job (you're looking at more than 10^30 distinct shapes for k=56 -- imagine if k = 10,000) but you may be able to get good enough for what you need by fitting for the first 50 values of k.
(Note: the reference in the wikipedia article takes care of duplicates with their definition of A_k.)
It seems that you are working on a problem that can be mapped to Markovian Walks.
If I understand your question, you are trying to count paths of length k like this:
Start (end)-> any pixel after visiting k neighbours
* - - - - -*
| |
| |
- - - -
in a structure that is similar to a chess board, and you want to connect only vertical and horizontal neighbours.
I think that you want the paths to be self avoiding, meaning that a pixel should not be traversed twice in a walk (meaning no loops). This condition lead to a classical problem called SAWs (Self Avoiding Walks).
Well, now the bad news: The problem is open! No one solved it yet.
You can find a nice intro to the problem here, starting at page 54 (or page 16, the counting is confusing because the page numbers are repeating in the doc). But the whole paper is very interesting and easy to read. It manages to explain the mathematical background, the historical anecdotes and the scientific importance of markovian chains in a few slides.
Hope this helps ... to avoid the problem.
If you were planning to iterate over all possible polyominos, I'm afraid you'll be waiting a long time. From the wikipedia site about polyominos, it's going to be at least O(4.0626^n) and probably closer to O(8^n). By the time n=14, the count will be over 5 billion and too big to fit into an int. By time n=30, the count will be more than 17 quintillion and you won't be able to fit it into a long. If all the world governments pooled together their resources to iterate through all polyominos in a 32 x 32 icon, they would not be able to do it before the sun goes supernova.
Now that doesn't mean what you want to do is intractable. It is likely almost all the work you do on one polyominal was done in part on others. It may be a fun task make an exponential speedup using dynamic programming. What is it you're trying to accomplish?
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I often hear complaints that programming languages that make heavy use of symbols for brevity, most notably C and C++ (I'm not going to touch APL), are difficult to type because they require frequent use of the shift key. A year or two ago, I got tired of it myself, downloaded Microsoft's Keyboard Layout Creator, made a few changes to my layout, and have not once looked back. The speed difference is astounding; with these few simple changes I am able to type C++ code around 30% faster, depending of course on how hairy it is; best of all, my typing speed in ordinary running text is not compromised.
My questions are these: what alternate keyboard layouts have existed for programming, which have gained popularity, are any of them still in modern use, do you personally use any altered layout, and how can my layout be further optimised?
I made the following changes to a standard QWERTY layout. (I don't use Dvorak, but there is a programmer Dvorak layout worth mentioning.)
Swap numbers with symbols in the top row, because long or repeated literal numbers are typically replaced with named constants;
Swap backquote with tilde, because backquotes are rare in many languages but destructors are common in C++;
Swap minus with underscore, because underscores are common in identifiers;
Swap curly braces with square brackets, because blocks are more common than subscripts; and
Swap double quote with single quote, because strings are more common than character literals.
I suspect this last is probably going to be the most controversial, as it interferes the most with running text by requiring use of shift to type common contractions. This layout has significantly increased my typing speed in C++, C, Java, and Perl, and somewhat increased it in LISP and Python.
I still hold that typing speed is not the main factor in the time it takes for a project to be completed. If it is, there is a big problem (Weeks of coding saves us hours of planning).
Regarding your question I prefer using the standard layout as it means I don't have to spend the first 10 minutes looking stupid when presented with a standard keyboard layout.
Some of the replacements you have suggested, e.g. the top row with the special characters doesn't make a ounce of difference as the outside finger on the other hand should be moving to shift at the same time.
IMHO One thing that helps above chaining layouts is using only keyboard shortcuts. Vim and Emacs are recommended. It makes moving text around far faster.
I would approach your question in the following way.
The task is to organise a keyboard in such way as to minimise key strokes and hand movement for given text.
Steps toward a possible solution.
Make a program that:
Takes a text file with source code. (The bigger the better and from various sources!)
Counts the frequency of use of each symbol (its presence in the text).
(optional) Based on step 2: The program generates key stroke count for each symbol plus how far the hand has to go from central position. As a result you will have a measure how effective your keyboard layout is.
Now manually or by writing a program Redefine your layout in the following way. Put most frequently used symbol in a central position closer to your strong hand. The second symbol goes to your weak hand in central position. The third symbol goes back to your strong hand...and so on. Then you gradually move from central position of the hands into more "distant" areas of the keyboard. When all keyboard is full then you continue the process of assigning keys but this time with Shift key pressed. The other difference would be that you do not rotate strong and weak hand for each symbol when the Shift is down. With shift key down first you would fill in central positions on the keyboard and then move to more distant positions.
When you do all that perform step 3 again for the new layout to see how the layout was improved.
You may have to carry your keyboard with you at all times. On the bright side nobody will touch your computer. It will make you look like a Pro.
Finally, don't forget to share your findings.
I'm playing with a variant of the Colemak layout at the moment with heavy changes of symbols:
without SHIFT:
` - { } [ ] ; < > ( ) _ =
q w f p g j l u y * / # \
a r s t d h n e i o '
z x c v b k m , . !
with SHIFT:
~ 1 2 3 4 5 6 7 8 9 0 & +
Q W F P G J L U Y # ^ $ |
A R S T D H N E I O "
Z X C V B K M % : ?
Maybe I'll restore the / key...
But this is not based on any sound research, and I'd also love to see a layout optimized (Optimization including stuff like hand alteration etc, also ZXCV preservation, ...) with a sourcecode based corpus, because all these layouts seem to be optimized for prose only. For example, 'f' is a very common letter in C (if, for).
Update: I'm currently using
` - { } [ ] # < > ( ) _ =
q w k r g y u l p * ; #
a s f t d h n e i o ' \
\ z x c v b j m , . /
with SHIFT:
~ 1 2 3 4 5 6 7 8 9 0 ^ +
Q W K R G Y U L P & ! $
A S F T D H N E I O " |
| Z X C V B J M % : ?
This is based on a 6-key-swap partial optimization taken from Carpalx with preservation of the usual Cut/Copy/Paste/Undo shortcuts and modified to give a better access to the usual programming characters.
Make a simple key logger, then count the number of times each key is pressed. Run it for a day or two, then save the output to a text file. Do this every once and a while. It doesn't matter what layout you are using, as you are just seeing which keys are being used the most.
If you want to make a good layout, you can't be afraid to go away from the norm. I'd suggest putting the top 11 keys along the home row, then the next top 11 keys as the top row (leave the 2 keys above the return key as the least used keys), then the 3rd top 11 keys as the bottom row. There should be 4 keys left over now. Take those and put them in the -= and ]\ slots. Congrats! You have now made a great keyboard layout for your purposes! =D
Overall, I think having a good text editor and knowing how to use it is better than trying to improve your typing speed. Being able to record and replay macros is sometimes a lifesaver, and a selection of shortcut-assigned code snippets can be handy because there's normally language-imposed limits on what can be turned into a library.
More generally, I think the real productivity enhancers are all about knowledge...
Knowing what tools and libraries are available and how to use them.
Knowing the overall structure of the code you're working on, not just your little bit.
Knowing key algorithms, design patterns and idioms so you don't have to reinvent them.
Knowing the rules well enough that you can be flexible - you know when to break them.
Knowing your co-workers and their strengths, weaknesses etc - ie knowing when to figure something out yourself, but also when and who to ask.
FWIW, I'm not claiming to be strong on all those. I've always been too biassed towards solving problems myself, and with too strong a tendency towards reinventing the wheel and grand architectural schemes.
Anyway, I just have this suspicion that time spent changing and learning keyboard layouts would be a distraction from more important issues.
Changing the keyboard layout is a bad idea since it would (perhaps) boost your typing speed on one keyboard, but severely damage your typing speed on other keyboards or on computers where you don't have your special keyboard layout. I've found that it is often better to adjust yourself to the defaults, that having to change them everywhere. (Personally, my fingers are heavily Emacs-biased, which causes lots of typing friction everywhere else.)