I have data looking like this:
| ID |OpID|
| -- | -- |
| 10 | 1 |
| 10 | 2 |
| 10 | 4 |
| 11 |null|
| 12 | 3 |
| 12 | 4 |
| 13 | 1 |
| 13 | 2 |
| 13 | 3 |
| 14 | 2 |
| 14 | 4 |
Here OpID 4 means 1 and 2.
I would like to count the different occurrences of 1, 2 and 3 in OpID of distinct ID.
If the counts of OpID having 1 would be 4, 2 would be 4, 3 would be 2.
If ID has OpID of 4 but already has data of 1, 2 it wouldn't be counted. But if 4 exists and only 1 (2) is there, count for 2 (1) would be incremented.
The expected output would be:
|OpID|Count|
| 1 | 4 |
| 2 | 4 |
| 3 | 2 |
(Going to be using the results in a column chart)
Hope this makes sense...
edit: there are other columns too and an ID and OpID can be duplicated hence need to do a groupby clause before.
#include<iostream>
using namespace std;
void combinationUtil(int arr[], int n, int r, int index, int data[], int i);
void printCombination(int arr[], int n, int r)
{
int data[r];
combinationUtil(arr, n, r, 0, data, 0);
}
void combinationUtil(int arr[], int n, int r, int index, int data[], int i)
{
if (index == r)
{
for (int j = 0; j < r; j++)
cout << data[j] << " ";
cout << endl;
return;
}
if (i >= n)
return;
data[index] = arr[i];
combinationUtil(arr, n, r, index + 1, data, i + 1);
combinationUtil(arr, n, r, index, data, i + 1);
}
int main()
{
int n = 5;
int arr[n] = { 1, 2, 3, 4, 5 };
int k = 3;
printCombination(arr, n, k);
return 0;
}
This is the code to print all possible subsets of length k. I didn’t understand the part how the function returns to the part where it prints the subset 134 after printing the subset 125. Please explain.
I even drew the tree, but how does the code create that "13" series after printing 125 . I'm quite weak at recursion, please correct me if there's a mistake in my code or tree.
Recursion Tree:
Let's inspect the programme execution (you can do this easily using a debugger).
Firstly since arr, n and r don't change in the call tree, let's note them down first:
n := 5, r := 3, arr := {1, 2, 3, 4, 5}
For the variable arguments let's build a table and note the first call to combinationUtil:
Callstack | index | i | data | Cases (printing, returning or recursing)
----------------------+-------+-------+-----------+------------------------------------
> combinationUtil | 0 | 0 | {., ., .} | recursing (index != r, i != n)
printCombination | | | |
main | | | |
Let's ignore main and printCombination in the future, but note that the top of the stack describes the function we've just entered with the given state of index, i and data (and arr, n, r but those won't change) - specifically we did not yet execute any of the body of the function like assigning data[index] = arr[i] or similar. Following the execution note how we're neither printing nor breaking out early since index != r and i != n meaning we'll recurse twice in this function call. Let's step to the first recursive call:
----------------------+-------+-------+-----------+------------------------------------
> combinationUtil | 1 | 1 | {1, ., .} | recursing
combinationUtil | 0 | 0 | |
When we enter our first recursive call, 1 will have been written to data so at the beginning of the function we can now see this value in data. We'll continue twice:
----------------------+-------+-------+-----------+------------------------------------
> combinationUtil | 2 | 2 | {1, 2, .} | recursing
combinationUtil | 1 | 1 | |
combinationUtil | 0 | 0 | |
----------------------+-------+-------+-----------+------------------------------------
> combinationUtil | 3 | 3 | {1, 2, 3} | printing (index == r)
combinationUtil | 2 | 2 | |
combinationUtil | 1 | 1 | |
combinationUtil | 0 | 0 | |
New case: index == r i.e. we'll loop over data, print its current content and return, one level higher we'll step into the next recursive call so let's look at the next steps:
----------------------+-------+-------+-----------+------------------------------------
> combinationUtil | 2 | 3 | {1, 2, 3} | recursing
combinationUtil | 2 | 2 | |
combinationUtil | 1 | 1 | |
combinationUtil | 0 | 0 | |
----------------------+-------+-------+-----------+------------------------------------
> combinationUtil | 3 | 4 | {1, 2, 4} | printing
combinationUtil | 2 | 3 | |
combinationUtil | 2 | 2 | |
combinationUtil | 1 | 1 | |
combinationUtil | 0 | 0 | |
----------------------+-------+-------+-----------+------------------------------------
> combinationUtil | 2 | 4 | {1, 2, 4} | recursing
combinationUtil | 2 | 3 | |
combinationUtil | 2 | 2 | |
combinationUtil | 1 | 1 | |
combinationUtil | 0 | 0 | |
----------------------+-------+-------+-----------+------------------------------------
> combinationUtil | 3 | 5 | {1, 2, 5} | printing
combinationUtil | 2 | 4 | |
combinationUtil | 2 | 3 | |
combinationUtil | 2 | 2 | |
combinationUtil | 1 | 1 | |
combinationUtil | 0 | 0 | |
----------------------+-------+-------+-----------+------------------------------------
> combinationUtil | 2 | 5 | {1, 2, 5} | returning (i >= n)
combinationUtil | 2 | 4 | |
combinationUtil | 2 | 3 | |
combinationUtil | 2 | 2 | |
combinationUtil | 1 | 1 | |
combinationUtil | 0 | 0 | |
Can you see how deep the call stack got until we printed 125? If you've been drawing the call graph along you should have something along the following now:
[] (0, 0)
/
1 (1, 1)
/
12 (2, 2)
/ \
123 12 (2, 3)
/ \
124 12 (2, 4)
/ \
125 ret (2, 5)
We're currently at ret and I've marked the arguments (index, i) from our current callstack along the root path (from [] to ret). We'll be returing in ret because i == n, we'll then return from each call up the tree until we reach 1 (index=1, i=1) where we return from its first recursion (index+1, i+1) so its next is (index, i+1) and the following next 6 steps together look like:
----------------------+-------+-------+-----------+------------------------------------
> combinationUtil | 1 | 2 | {1, 2, 5} | recursing
combinationUtil | 1 | 1 | |
combinationUtil | 0 | 0 | |
----------------------+-------+-------+-----------+------------------------------------
> combinationUtil | 2 | 3 | {1, 3, 5} | recursing
combinationUtil | 1 | 2 | |
combinationUtil | 1 | 1 | |
combinationUtil | 0 | 0 | |
----------------------+-------+-------+-----------+------------------------------------
> combinationUtil | 3 | 4 | {1, 3, 4} | printing
combinationUtil | 2 | 3 | |
combinationUtil | 1 | 2 | |
combinationUtil | 1 | 1 | |
combinationUtil | 0 | 0 | |
----------------------+-------+-------+-----------+------------------------------------
> combinationUtil | 2 | 4 | {1, 3, 4} | recursing
combinationUtil | 2 | 3 | |
combinationUtil | 1 | 2 | |
combinationUtil | 1 | 1 | |
combinationUtil | 0 | 0 | |
----------------------+-------+-------+-----------+------------------------------------
> combinationUtil | 3 | 5 | {1, 3, 5} | printing
combinationUtil | 2 | 4 | |
combinationUtil | 2 | 3 | |
combinationUtil | 1 | 2 | |
combinationUtil | 1 | 1 | |
combinationUtil | 0 | 0 | |
----------------------+-------+-------+-----------+------------------------------------
> combinationUtil | 2 | 5 | {1, 3, 5} | returning
combinationUtil | 2 | 4 | |
combinationUtil | 2 | 3 | |
combinationUtil | 1 | 2 | |
combinationUtil | 1 | 1 | |
combinationUtil | 0 | 0 | |
And the call graph up to this point looks like:
[] (0, 0)
/
1 (1, 1)
/-------^-------\
12 1 (1, 2)
/ \ /
123 12 13 (2, 3)
/ \ / \
124 12 134 13 (2, 4)
/ \ / \
125 ret 135 ret (2, 5)
Your code is an example of DFS (Depth First Search). For every node, it first recurs on the leftmost child, then when it's at the rightmost child, this "part" of the function ends, essentially going back to the previous node and recurring on its children. Basically, children have priority over siblings, and left has priority over right.
If any part of this post is unclear, tell me and I will elaborate. Welcome to Stack Overflow :)
I have the following SCIP solver log
time | node | left |LP iter|LP it/n| mem |mdpt |frac |vars |cons |cols |rows |
0.0s| 1 | 0 | 4 | - | 6k| 0 | 0 | 6 | 200 | 6 | 200 |
0.0s| 1 | 0 | 7 | - | 6k| 0 | 0 | 8 | 200 | 8 | 200 |
0.0s| 1 | 0 | 10 | - | 6k| 0 | 0 | 9 | 200 | 9 | 200 |
0.0s| 1 | 0 | 10 | - | 6k| 0 | 0 | 9 | 200 | 9 | 200 |
0.0s| 1 | 0 | 10 | - | 6k| 0 | 0 | 9 | 200 | 9 | 200 |
0.0s| 1 | 0 | 10 | - | 6k| 0 | 0 | 9 | 200 | 9 | 200 |
I want the log to be more verbose, as in display a new line at each LP iteration. So far I only came across
SCIP_CALL( SCIPsetIntParam(scip, "display/verblevel", 5));
This is increasing but not as much as I want and not where I want. Essentially I would like to have lines at LP iter 4, 5, 6, 7, 8, 9 and 10 too.
You cannot print a line of SCIP output at every LP iteration. You can set display/freq to 1, then SCIP will display a line at every node.
Additionally you can set display/lpinfo to true, then the LP solver will print additional information. I don't think any LP solver will print you a line for every LP iteration though . Do you use SCIP with SoPlex?
Edit: Looked and you can set the SoPlex frequency to 1 with the parameter "--int:displayfreq". I don't think you can set this through the SCIP api though. If you only want to solve the LP you could just do it in SoPlex or you would have to edit the lpi_spx2 source code.
How to increase column values from:
1 | 1 | 7.317073
2 | 1 | 14.634146
3 | 1 | 24.390244
4 | 2 | 7.317073
5 | 2 | 14.634146
6 | 2 | 24.390244
To:
1 | 1 | 7.317073
2 | 1 | 14.634146
3 | 1 | 24.390244
4 | 2 | 7.317073
5 | 2 | 14.634146
6 | 2 | 24.390244
7 | 3 | 7.317073
8 | 3 | 14.634146
9 | 3 | 24.390244
10 | 4 | 7.317073
11 | 4 | 14.634146
12 | 4 | 24.390244
I'm using Open Office.
Assuming that the top left corner is A1, set the fourth row such:
A4: =A3+1
B4: =roundup(A4/3)
C4 =C1
And pull them up to row 12
For ColumnA simply selecting the first three rows, grabbing the fill handle (black square at the bottom right of the range) and dragging down to suit should be sufficient.
An alternative here to ROUNDUP is, in B1 and copied down:
=INT((ROW()-1)/3)+1
For ColumnC as for ColumnA but with Crl depressed.
I would like to check if a value has appeared in some previous row of the same column.
At the end I would like to have a cumulative count of the number of distinct observations.
Is there any other solution than concenating all _n rows and using regular expressions? I'm getting there with concatenating the rows, but given the limit of 244 characters for string variables (in Stata <13), this is sometimes not applicable.
Here's what I'm doing right now:
gen tmp=x
replace tmp = tmp[_n-1]+ "," + tmp if _n > 1
gen cumu=0
replace cumu=1 if regexm(tmp[_n-1],x+"|"+x+",|"+","+x+",")==0
replace cumu= sum(cumu)
Example
+-----+
| x |
|-----|
1. | 12 |
2. | 32 |
3. | 12 |
4. | 43 |
5. | 43 |
6. | 3 |
7. | 4 |
8. | 3 |
9. | 3 |
10. | 3 |
+-----+
becomes
+-------------------------------+
| x | tmp |
|-----|--------------------------
1. | 12 | 12 |
2. | 32 | 12,32 |
3. | 12 | 12,32,12 |
4. | 43 | 3,32,12,43 |
5. | 43 | 3,32,12,43,43 |
6. | 3 | 3,32,12,43,43,3 |
7. | 4 | 3,32,12,43,43,3,4 |
8. | 3 | 3,32,12,43,43,3,4,3 |
9. | 3 | 3,32,12,43,43,3,4,3,3 |
10. | 3 | 3,32,12,43,43,3,4,3,3,3|
+--------------------------------+
and finally
+-----------+
| x | cumu|
|-----|------
1. | 12 | 1 |
2. | 32 | 2 |
3. | 12 | 2 |
4. | 43 | 3 |
5. | 43 | 3 |
6. | 3 | 4 |
7. | 4 | 5 |
8. | 3 | 5 |
9. | 3 | 5 |
10. | 3 | 5 |
+-----------+
Any ideas how to avoid the 'middle step' (for me that gets very important when having strings in x instead of numbers).
Thanks!
Regular expressions are great, but here as often elsewhere simple calculations suffice. With your sample data
. input x
x
1. 12
2. 32
3. 12
4. 43
5. 43
6. 3
7. 4
8. 3
9. 3
10. 3
11. end
end of do-file
you can identify first occurrences of each distinct value:
. gen long order = _n
. bysort x (order) : gen first = _n == 1
. sort order
. l
+--------------------+
| x order first |
|--------------------|
1. | 12 1 1 |
2. | 32 2 1 |
3. | 12 3 0 |
4. | 43 4 1 |
5. | 43 5 0 |
|--------------------|
6. | 3 6 1 |
7. | 4 7 1 |
8. | 3 8 0 |
9. | 3 9 0 |
10. | 3 10 0 |
+--------------------+
The number of distinct values seen so far is then just a cumulative sum of first using sum(). This works with string variables too. In fact this problem is one of several discussed within
http://www.stata-journal.com/sjpdf.html?articlenum=dm0042
which is accessible to all as a .pdf. search distinct would have pointed you to this article.
Becoming fluent with what you can do with by:, sort, _n and _N is an important skill in Stata. See also
http://www.stata-journal.com/sjpdf.html?articlenum=pr0004
for another article accessible to all.