Permutations with repetitions - permutation

Is there any inbuilt function in Julia language that permutes a given list with repetitions
There are n^n such permutations for a list of n elements

Not entirely sure what you're asking for, but the cartesian product iterator in the Iterators.jl package might be along those lines.
https://github.com/JuliaLang/Iterators.jl/blob/master/src/Iterators.jl#L204
(Not inbuilt, if that matters to you for some reason. Also, Iterators.jl could use better documentation...)

Related

efficient way to remove duplicate pairs of integers in C

I've found answers to similar problems, but none of them exactly described my problem.
so on the risk of being down-voted to hell I was wondering if there is a standard method to solve my problem. Further, there's a chance that I'm asking the wrong question. Maybe the problem can be solved more efficiently another way.
So here's some background:
I'm looping through a list of particles. Each particle has a list of it's neighboring particles. Now I need to create a list of unique particle pairs of mutual neightbours.
Each particle can be identified by an integer number.
Should I just build a list of all the pair's including duplicates and use some kind of sort & comparator to eliminate duplicates or should I try to avoid adding duplicates into my list in the first place?
Performance is really important to me. I guess most of the loops may be vectorized and threaded. On average each particle has around 15 neighbours and I expect, that there will be 1e6 particles at most.
I do have some ideas, but I'm not an experienced coder and I don't want to waste 1 week to test every single method by benchmarking different situations just to find out that there's already a standard meyjod for my problem.
Any suggestions?
BTW: I'm using C.
Some pseudo-code
for i in nparticles
particle=particles[i]; //just an array containing the "index" of each particle
//each particle has a neightbor-list
for k in neighlist[i] //looping through all the neighbors
//k represent the index of the neighbor of particle "i"
if the pair (i,k) or (k,i) is not already in the pair-list, add it. otherwise don't
Sorting the elements each iteration is not a good idea since comparison sort is O(n log n) complex.
The next best thing would be to store the items in a search tree, better yet binary search tree, and better yet self equalizing binary search tree, you can find implementations on GitHub.
Even better solution would give an access time of O(1), you can achieve this in 2 different ways one is a simple identity array, where at each slot you would save say a pointer to item if there is on at this id or some flag defining that current id is empty. This is very fast but wasteful. You'll need O(N) memory.
The best solution in my opinion would be to use a set or a has-map. Which are basically the same because sets can be implemented using hash-map.
Here is a github project with c hash-map implementation.
And stack overflow answer to a similar question.

Finding arrays that satisfy the average case

I'm not sure whether to post this is Mathematics or here, but it's Algorithms, so I'm going to try here.
Essentially, I have an algorithm to find the median value in an array. It is, in essence, the quick select algorithm.
What I want to do is find arrays of numbers that satisfy the average case. I.E, when the array length is 5, the average number of basic operations is 6. I want to find the relationship between the arrays that output 6, so that I can programatically build an array of length x, and get the number of operations
I've been generating a tonne of arrays to try and find a pattern by hand, and I can't see it. I have been using the permutations of {1,2,3,4,5}, and going higher than that and it becomes too unwieldy to look at (minimum 720 arrays), and lower there is not enough variation to find a pattern.
The way I found 6 basic operations was to run the algorithm over ever permutation of {1,2,3,4,5}, and output the result into a list, which I then piped into python and ran sum(list)/len(list). I then manually went through and found the arrays that output 6, and looked at them. First alone, and then in the group, to see if I could find any characteristics.
The first pivot is always zero.
I'm either looking for some kind of formula to generate these arrays, or a way to analyse the data to obtain the pattern.
Edit:
I should clarify that I am looking for a way to programmatically generate arrays that meets the criteria of 'average case' for the quick select.

How to find minimum element in an array repeatedly but between different indices input by user.

An array of n numbers is given. Number of times minimum to be found out is given,let it be p, Indices are also given for each case repeatedly . I traversed the array to find min in array between given indices and repeated this procedure p times using for loop but I want it to be more efficient, How can I do so?
What you need, is to use some efficient algorithm for Range Minimum Query problem. Please follow the provided link. There you will find a comprehensive explanation how to do this.
Depends on the number of queries, the kind of queries etc.
Without any such information, taking an O(n) time pre-processing hit for Range Minimum Query setup will make each of the min queries O(1).
Depending on the expected query patterns etc, there are tradeoffs that you can make.

How to know if an array is sorted?

I already read this post but the answer didn't satisfied me Check if Array is sorted in Log(N).
Imagine I have a serious big array over 1,000,000 double numbers (positive and/or negative) and I want to know if the array is "sorted" trying to avoid the max numbers of comparisons because comparing doubles and floats take too much time. Is it possible to use statistics on It?, and if It was:
It is well seen by real-programmers?
Should I take samples?
How many samples should I take
Should they be random, or in a sequence?
How much is the %error permitted to say "the array sorted"?
Thanks.
That depends on your requirements. If you can say that if 100 random samples out of 1.000.000 is enough the assume it's sorted - then so it is. But to be absolutely sure, you will always have to go through every single entry. Only you can answer this question since only you know how certain you need to be about it being sorted.
This is a classic probability problem taught in high school. Consider this question:
What is the probability that the batch will be rejected?
In a batch of 8,000, clocks 7% are defective. A random sample of 10 (without replacement) from the 8,000 is selected and tested. If at least one is defective the entire batch will be rejected.
So you can take a number of random samples from your large array and see if it's sorted, but you must note that you need to know the probability that the sample is out of order. Since you don't have that information, a probabilistic approach wouldn't work efficiently here.
(However, you can check 50% of the array and naively conclude that there is a 50% chance that it is sorted correctly.)
If you run a divide and conquer algorithm using multiprocessing (real parallelism, so only for multi-core CPUs) you can check whether an array is sorted or not in Log(N).
If you have GPU multiprocessing you can achieve Log(N) very easily since modern graphics card are able to run few thousands processes in parallel.
Your question 5 is the question that you need to answer to determine the other answers. To ensure the array is perfectly sorted you must go through every element, because any one of them could be the one out of place.
The maximum number of comparisons to decide whether the array is sorted is N-1, because there are N-1 adjacent number pairs to compare. But for simplicity, we'll say N as it does not matter if we look at N or N+1 numbers.
Furthermore, it is unimportant where you start, so let's just start at the beginning.
Comparison #1 (A[0] vs. A[1]). If it fails, the array is unsorted. If it succeeds, good.
As we only compare, we can reduce this to the neighbors and whether the left one is smaller or equal (1) or not (0). So we can treat the array as a sequence of 0's and 1's, indicating whether two adjacent numbers are in order or not.
Calculating the error rate or the propability (correct spelling?) we will have to look at all combinations of our 0/1 sequence.
I would look at it like this: We have 2^n combinations of an array (i.e. the order of the pairs, of which only one is sorted (all elements are 1 indicating that each A[i] is less or equal to A[i+1]).
Now this seems to be simple:
initially the error is 1/2^N. After the first comparison half of the possible combinations (all unsorted) get eliminated. So the error rate should be 1/2^n + 1/2^(n-1).
I'm not a mathematician, but it should be quite easy to calculate how many elements are needed to reach the error rate (find x such that ERROR >= sum of 1/2^n + 1/2^(n-1)... 1/^(2-x) )
Sorry for the confusing english. I come from germany..
Since every single element can be the one element that is out-of-line, you have to run through all of them, hence your algorithm has runtime O(n).
If your understanding of "sorted" is less strict, you need to specify what exaclty you mean by "sorted". Usually, "sorted" means that adjacent elements meet a less or less-or-equal condition.
Like everyone else says, the only way to be 100% sure that it is sorted is to run through every single element, which is O(N).
However, it seems to me that if you're so worried about it being sorted, then maybe having it sorted to begin with is more important than the array elements being stored in a contiguous portion in memory?
What I'm getting at is, you could use a map whose elements by definition follow a strict weak ordering. In other words, the elements in a map are always sorted. You could also use a set to achieve the same effect.
For example: std::map<int,double> collectoin; would allow you to almost use it like an array: collection[0]=3.0; std::cout<<collection[0]<<std:;endl;. There are differences, of course, but if the sorting is so important then an array is the wrong choice for storing the data.
The old fashion way.Print it out and see if there in order. Really if your sort is wrong you would probably see it soon. It's more unlikely that you would only see a few misorders if you were sorting like 100+ things. When ever I deal with it my whole thing is completely off or it works.
As an example that you probably should not use but demonstrates sampling size:
Statistically valid sample size can give you a reasonable estimate of sortedness. If you want to be 95% certain eerything is sorted you can do that by creating a list of truly random points to sample, perhaps ~1500.
Essentially this is completely pointless if the list of values being out of order in one single place will break subsequent algorithms or data requirements.
If this is a problem, preprocess the list before your code runs, or use a really fast sort package in your code. Most sort packages also have a validation mode, where it simply tells you yes, the list meets your sort criteria - or not. Other suggestions like parallelization of your check with threads are great ideas.

3 partition mergesort

My professor assigned my class with implementing mergesort in arrays with 3-part partitioning and merging.
That was the exact question from the professor. Problem is I have found no such thing as a 3-way mergesort I only know of a 3-way quicksort so I thought that he probably meant to take an array, split it into 3 parts and then mergesort those 3 parts together and I'm doing this by mergesorting the first 2 parts together and then mergesorting the combined part with the 3rd part.
Did I think correctly and did I do the right thing (already implemented but I'm not posting the code since it doesn't have anything to do with my question) or have I understood wrong and there is something like a 3-way mergesort that I am not aware of.
The professor tends to give us assignments that have to do with stuff that we have not learned yet that's why I'm so sceptical about this and I looked as much as I could in Google etc.
Once you mergesorted the three sub arrays, you can merge them together in one go: compare the first elements of all three and place the smallest into the combined array, then take the next element from the array you took the smallest from and do the compariosn again until all subarray elements are accounted for.
Make sure you hande the case where there are only two elements in the array (so you cannot partition it into three non-empty parts). Also, in the above paragraph, one array will be empty before the others when merging, so you need to account for that too.
It is called a three part merge sort, because thats what it does.
Take a look at http://mathbits.com/MathBits/CompSci/Arrays/Merge.htm

Resources