I have a list of names in a 2-D array. My program performs some computations and assign these names their respective marks. I am supposed to send the output to a file but I am facing some problems. The problem is the length of each name in the array varies and it has affected my output format. I am looping through the array to print out the names and their values. The output comes nicely when I omit the name.
Name of Pupils/Students Indiv-Test Group Work Class T.
4 3 2
6 15 12
But as soon as I bring the names, then the output changes.
Name of Pupils/Students Indiv-Test Group Work Class T.
1.nana yaw kwadwo 15 14 13 1
2.kwaku 12 15 15
3.osei kofi 12 14 1
So it is the length of the names that affect my output format. Please is there any way, I can get a nice output format like my first sample output together with the names; like this. Still maintaining the length of my names. Highly required.Thank you in advance.
Name of Pupils/Students Indiv-Test Group Work Class T.
1.nana yaw kwadwo 4 3 2
2.kwaku 6 15 12
3.osei kofi 12 14 1
I have tried every output format I know but yet still.
This is my sample code;
for (int n=0;n<=num;n++)
{
name_output<<n+1<<"."<<sample[n];
name_output<<setw(37)<<s.indiv_test[n]<<setw(16)<<s.grp_work[n]<<setw(17) <<s.class_test[n]
}
Let's say I was comparing two adjacent lines to each other after running sort -u on a file. I find they both match n-characters over from the left side, then begin to disagree at some point, and where the disagreement begins, the first line had a digit "0" to "9". The second line has a non-digit. I want the two lines to swap positions. Why do I want this? Because the digit in the first line meand it is a longer number, and needs to go behind the other, so that these lines, regardless of the digit value, will rearrange from this:
xxxx-xxxx-xxxxxxx.xxxxxxx.xxxx.DD-xx.x.x.x
xxxx-xxxx-xxxxxxx.xxxxxxx.xxxx.D-xx.x.x.x
to this:
xxxx-xxxx-xxxxxxx.xxxxxxx.xxxx.D-xx.x.x.x
xxxx-xxxx-xxxxxxx.xxxxxxx.xxxx.DD-xx.x.x.x
And this:
1
10
11
12
13
14
15
2
3
4
5
6
7
8
9
becomes this:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
because it forces numeric values with the same number of digits to be
compared with each other, as those grouped from the left with more digits are moved behind those with fewer digits.
My logic might break down at some point, but until I can code it, I can't check the results returned. So does anybody know how to do this in bash?
sort -g (general numeric sort) should do the trick.
Hi I am writing a matlab code at the moment. I am trying to compare the values in a list to the number 10 and if the value is less than 10 add 1 to the total. However I cannot seem to get the code right. My code so far
tot = 0
for i=1:n
if(x(i)<10)
tot = +1
else
y=0;
end
end
tot
The value I get for tot always = 1 and never increases? Can someone help edit this or if not provide a solution to the problem?
I would agree with the answer mentioned above, that one should avoid for loops for this. There can be a faster solution. Since, he is just interested in the counts, and not value of numbers, so there is no need to index things back.
Given:
a = [1 2 3 4 5 6 7 8 9 10 11 12 13 14 15]
Computing numbers less than 10 (you could put any number here)
answer = sum(a<10);
Good luck!
In languages like MATLAB and R, you really should not use for loops like this, even as an exercise. Each variable can be a vector, and operations can occur on the whole vector at once, rather than element-by-element.
Given:
x = [ 1 2 3 4 11 12 13 14 15 16 ]
To generate a list of all x less than 10 you would say:
x(x<10)
So to count them:
total = length(x(x<10))
No loop needed or wanted!
I'm looking for a reversible function unsigned f(unsigned) for which the number of bits set in f(i) increases with i, or at least does not decrease. Obviously, f(0) has to be 0 then, and f(~0) must come last. In between there's more flexibility. After f(0), the next 32* values must be 1U<<0 to 1U<<31, but I don't care a lot about the order (they all have 1 bit set).
I'd like an algorithm which doesn't need to calculate f(0)...f(i-1) in order to calculate f(i), and a complete table is also unworkable.
This is similar to Gray codes, but I can't see a way to reuse that algorithm. I'm trying to use this to label a large data set, and prioritize the order in which I search them. The idea is that I have a key C, and I'll check labels C ^ f(i). Low values of i should give me labels similar to C, i.e. differing in only a few bits.
[*] Bonus points for not assuming that unsigned has 32 bits.
[example]
A valid initial sequence:
0, 1, 2, 4, 16, 8 ... // 16 and 8 both have one bit set, so they compare equal
An invalid initial sequence:
0, 1, 2, 3, 4 ... // 3 has two bits set, so it cannot precede 4 or 2147483648.
Ok, seems like I have a reasonable answer. First let's define binom(n,k) as the number of ways in which we can set k out of n bits. That's the classic Pascal triangle:
1 1
1 2 1
1 3 3 1
1 4 6 4 1
1 5 10 10 5 1
1 6 15 20 15 6 1
1 7 21 35 35 21 7 1
1 8 28 56 70 56 28 8 1
...
Easily calculated and cached. Note that the sum of each line is 1<<lineNumber.
The next thing we'll need is the partial_sum of that triangle:
1 2
1 3 4
1 4 7 8
1 5 11 15 16
1 6 16 26 31 32
1 7 22 42 57 63 64
1 8 29 64 99 120 127 128
1 9 37 93 163 219 247 255 256
...
Again, this table can be created by summing two values from the previous line, except that the new entry on each line is now 1<<line instead of 1.
Let's use these tables above to construct f(x) for an 8 bits number (it trivially generalizes to any number of bits). f(0) still has to be 0. Looking up the 8th row in the first triangle, we see that next 8 entries are f(1) to f(9), all with one bit set. The next 28 entries (7+6+5+4+3+2+1) all have 2 bits set, so that's f(10) to f(37). The next 56 entries, f(38) to f(93) have 3 bits, and there are 70 entries with 4 bits set. From symmetry we can see that they're centered around f(128), in particular they're f(94) to f(163). And obviously, the only number with 8 bits set sorts last, as f(255).
So, with these tables we can quickly determine how many bits must be set in f(i). Just do a binary search in the last row of your table. But that doesn't answer exactly which bits are set. For that we need the previous rows.
The reason that each value in the table can be created from the previous line is simple. binom(n,k) == binom(k, n-1) + binom(k-1, n-1). There are two sorts of numbers with k bits set: Those that start with a 0... and numbers which start with 1.... In the first case, the next n-1 bits must contain those k bits, in the second case the next n-1 bits must contain only k-1 bits. Special cases are of course 0 out of n and n out of n.
This same stucture can be used to quickly tell us what f(16) must be. We already had established that it must contain 2 bits set, as it falls in the range f(10) - f(37). In particular, it's number 6 with 2 bits set (starting as usual with 0). It's useful to define this as an offset in a range as we'll try to shrink the length this range from 28 down to 1.
We now subdivide that range into 21 values which start with a zero and 7 which start a one. Since 6 < 21, we know that the first digit is a zero. Of the remaining 7 bits, still 2 need to be set, so we move up a line in the triangle and see that 15 values start with two zeroes, and 6 start with 01. Since 6 < 15, f(16) starts with 00. Going further up, 7 <= 10 so it starts with 000. But 6 == 6, so it doesn't start with 0000 but 0001. At this point we change the start of the range, so the new offset becomes 0 (6-6)
We know need can focus only on the numbers that start with 0001 and have one extra bit, which are f(16)...f(19). It should be obvious by know that the range is f(16)=00010001, f(17)=00010010, f(18)=00010100, f(19)=00011000.
So, to calculate each bit, we move one row up in the triangle, compare our "remainder", add a zero or one based on the comparison possibly go left one column. That means the computational complexity of f(x) is O(bits), or O(log N), and the storage needed is O(bits*bits).
For each given number k we know that there are binom(n, k) n-bit integers that have exactly k bits of value one. We can now generate a lookup table of n + 1 integers that store for each k how many numbers have less one bits. This lookup table can then be used to find the number o of one bits of f(i).
Once we know this number we subtract the lookup table value for this number of bits from i which leaves us with the permutation index p for numbers with the given number of one bits. Altough I have not done research in this area I am quite sure that there exists a method for finding the pth permutation of a std::vector<bool> which is initialized with zeros and o ones in the lowest bits.
The reverse function
Again the lookup table comes in handy. We can directly calculate the number of preceding numbers with less one bits by counting the one bits in the input integer and reading in the lookup table. Then you "only" need to determine the permutation index and add it to the looked up value and you are done.
Disclaimer
Of course this is only a rough outline and some parts (especially involving the permutations) might take longer than it sounds.
Addition
You stated yourself
I'm trying to use this to label a large data set, and prioritize the order in which I search them.
Which sounds to me as if you would be going from the low hamming distance to the high hamming distance. In this case it would be enough to have an incremental version which generates the next number from the previous:
unsigned next(unsigned previous)
{
if(std::next_permutation(previous))
return previous;
else
return (1 << (1 + countOneBits(previous))) - 1;
}
Of course std::next_permutation permutation does not work this way but I think it is clear how I mean to use it.
I have read an article on Internet and know that the natural way of decoding by traversing from root but I want to do it faster with a lookup table.
After reading, I still cannot get the points.
ex:
input:"abcdaabaaabaaa"
code data
0 a
10 b
110 c
111 d
The article says that due to variable length, it determine the length by taking a bit of string of
max code length and use it as index.
output:"010110111001000010000"
Index Index(binary) Code Bits required
0 000 a 1
1 001 a 1
2 010 a 1
3 011 a 1
4 100 b 2
5 101 b 2
6 110 c 3
7 111 d 3
My questions are:
What does it means due to variable length, it determine the length by taking a bit of string of
max code length? How to determine the length?
How to generate the lookup table and how to use it? What is the algorithm behind?
For your example, the maximum code length is 3 bits. So you take the first 3 bits from your stream (010) and use that to index the table. This gives code, 'a' and bits = 1. You consume 1 bit from your input stream, output the code, and carry on. On the second go around you will get (101), which indexes as 'b' and 2 bits, etc.
To build the table, make it as large as 1 << max_code_length, and fill in details as if you are decoding the index as a huffman code. If you look at your example all the indices which begin '0' are a, indices beginning '10' are b, and so on.