Assume a long bitstream of bits. I want to discover some patterns in this bitstream. What I know is that this bitstream is not a random bitstream and contains some repetitive pattern.
As an example, assume that the bitstream is as below:
010100000101000101010010010100110101...
There is a known pattern in this bitstream: some values are set between 0101s. If we separate this bitstream 4 by 4 bits we will see that some values are set between some 0101 pattern.
0101 0000 0101 0001 0101 0010 0101 0011 0101...
Is there any way to find or recognize a pattern for values between 0101 or some other possible pattern?
I understand the whole, it shifts the bits over
0000 0000 0000 0000 0000 0000 0000 0111 << 1
0000 0000 0000 0000 0000 0000 0000 1110
But why would you want to use these left and right shift operators instead of just typing out the number, where does using these operators actually have a benefit.
I see a lot of answers on Stackoverflow and what the operator accomplishes, but nobody ever says WHY they would use it over just typing out 12345 so like I said, why use them and what is their benefit over just typing the number out you're trying to get?
I came across this code while browsing a package on github:
// ClientVersion is the protocol version that Client implements.
const ClientVersion = 1<<16 | 3<<8 | 0
Which the number comes out to be: 66304
So if this is a constant why not just type const ClientVersion = 66304 why use the operators.
If you assume a an integer, then a << x multiplies a by 2^x and a >> x divides b by 2^x, where you use an integer division.
In the case that you described I see no real benefit of using 1<<16 | 3<<8 | 0 instead of 66304 (except of show-off that you can use bitwise operators, which in my stupid opinion is stupid).
But there are ways where I think that they are justifiable (take a look at this question about iota constants).
A couple of other examples (not only related to Go):
check if n-th bit is set x & (1<<n)
set the n-th bit x | (1<<n)
many other manipulations with n-th bit.
When you require small memory footprints, being able to use a single byte to hold 256 different options instead of using a big string array or more bytes then you will use these.
Embedded systems make use of bit wise operations to turn on/off options, any system that needs to be somewhat self sustainable and not depend on a rich external datastore would benefit from this technique.
Hi the following code in Lua:
letters = "Vocéá"
print(string.match("¡Você","["..letters.."]+"))
returns:
�Voc�
if I replace é with regular e and get rid of á then I get "Voc". seems that á interferes with ¡, and é with ê. Could it be that they share a byte in common?
I am not an expert in encoding, but these are the utf16 values,utf8 binaries:
á(feff00e1) 1100 0011 1010 0001
¡(feff00a1) 1100 0010 1010 0001
ê(feff00ea) 1100 0011 1010 1010
é(feff00e9) 1100 0011 1010 1001
How am I to ignore the portuguese character & the "¡" (and many others I am not aware of)?
Maybe this is not the best approach anyways. I am trying to build a spanish tokenizer. I am surprised though that the match function returns a question mark from a character that is not included in my match list.
Characters and bytes are two different things. Characters can be encoded in bytes in various ways, using different encodings. One possible encoding is UTF-8. Unfortunately Lua's string.match doesn't know almost anything about charactes and encodings, it only works with bytes.
So your script is not looking for the "V", "c", "o", "á", "é" characters, but for the "\x56", "\x63", "\x6F", "\xA1", "\xA9", "\xC3" bytes.
I only know what I know through my experience through Computer Architecture course. Little-endian stores the LSB on the right and MSB on the left and on Big-endian it's vice versa.
That would mean a byte representation of 18 is 0001 0010 and on Big-endian it would be 0100 1000.
No, it is not like that, say you have 3,168,415,017 as 32 bit unsigned number here is the Little Endian binary representation of it:
10111100 11011010 00101101 00101001
While the Big Endian representation would flip the BYTES but not the BITS inside the bytes.
00101001 00101101 11011010 10111100
Note that the bytes are flipped but the order of bits inside of each remains the same.
I have 4 binary bits
Bit 3 Bit 2 Bit 1 Bit 0
Normally the answer is simple: 2^4, or 16 different combinations; and it would looks something like the following:
0000 0001 0010 0011 0100 0101 0110 0111 1000 1001 1010 1011 1100 1101 1110 1111
However, The LSB (Bit 0) changes state every iteration.
I need an algorithm where the state of a bit only changes once through all the iterations; i.e, I need all my bits to act like the MSB (Bit 3).
How can I do this?
Edit
It seems that most people are converging to there being only 5 possible solutions. However this assumes there is a starting point for the value and an ending point. This doesn't matter so I'm going to give a real world scenario to better explain.
Suppose I have an digital alarm clock that gives me 4 outputs. Each output can be programmed to go on at a certain time and off at a certain time and are programmed independent of each other, eg. I can program output 1 to go on at 1 am and off at 3 am, while I can program output 2 to go on at 7 pm and off at 2 am. There are no restrictions to how long each output can stay on.
Now I want to hook this alarm clock to a computer and get as close as possible to the current correct time. i.e If the clock says the time is 2:15 pm, my computer knows that the alarm is within the 12 pm to 6 pm range for example. I want to be able to get the smallest possible range. Whats the smallest possible range I can get?
There are 4 bits.
Each bit may change state only once.
For each new value, at least one of the bits must have changed state from the previous value.
Therefore, you can have at most 4 state changes, and at most 5 different values.
Example:
0000 -> 0001 -> 0011 -> 0111 -> 1111
Edit:
Very well, let's restate from what you mean rather than from what you say.
There are 4 bits.
Each bit may change state only twice. (once from 0 to 1, and once from 1 to 0)
For each new value, at least one of the bits must have changed state from the previous value.
Therefore, you can have at most 8 state changes, and at most 8 different values (since the last state change necessarily brings all bits back to their initial state)
Example:
0000 -> 0001 -> 0011 -> 0111 -> 1111 -> 1110 -> 1100 -> 1000 -> 0000
So, by setting the outputs for: 3 AM - 3 PM, 6 AM - 6 PM, 9 AM - 9 PM and noon - midnight, you can determine which 3-hour period it is from the outputs. I'd suggest plugging wires into the visual output instead.
You want a Gray Code. Look about half way down for "Constructing an n-bit gray code".
I believe it is impossible to cycle though all possible bit patterns with such a restriction.
If you have an n-bit idea, you can cycle though a total of (n+1) states before having to flip a bit you've already flipped.
For example, in a 3-bit example, if you start with 111, you get
111
110
100
000
And then you're forced to flip one you've already flipped to get a new state.
Based on your alarm clock example I assume you need to finish on the combiation you started on, and that each bit can be cycled on then off only once, e.g.
0000 -> 0001 -> 0011 -> 0111 -> 1111
-> 1110 -> 1100 -> 1000 -> 0000
The number of steps is twice the number of bits, so with 4 bits you could get the current time to within a 3 hour range.
You want each bit to change only once?
Like:
0000 -> 0001 -> 0011 -> 0111 -> 1111
In that case you can use a simple counter where the delta is multiplied by 2 each iteration (or shift left).
If Gamecat got you correctly,
your bitmask values will be:
1 - 1
2 - 1
4 - 1
8 - 1
16 - 1
etc.
2^i - 1
or, using shifts:
(1 << i) - 1 for i in 0..
"I need an algorithm where the state of a bit only changes once through all the iterations"
If the above statement is taken literally, then there are only five states per iteration, as explained in other posts.
If the question is "How many possible sequences can be generated?", then:
Is the first state always 0000?
If not, then you have 16 possible initial states.
Does order matter?
If yes, then you have 4! = 24 possible ways to choose which bits to flip first.
So, this gives a total of 16*24 = 384 possible sequences that can be generated.
Looking back at the original question i think i understand what you mean
simply whats the smallest amount of bits you can use to program a clock, based on the amount of possible bit combinations
the first question is how many sequences are required.
60Secs x 60 Mins x 24hrs = 86400 (combinations required)
the next step is to work out how many bit are required to produce at least 86400 combinations
if somebody know the calculation to
how many bits can produce 86400 combinations then thats your answer.
hopefully there is a formula online somewhere for this calculation
Here is an example to how you can keep a bit from only being flipped once. Not knowing all the parameter of you system it is not easy to give an accurate example but here is one anyway.
char bits = 0x05;
flipp_bit(char bit_flip)
{
static char bits_flipped=0;
if( (bits_flipped & bit_flip) == 0)
{
bits_flipped |= bit_flip;
bits ^= bit_flip;
}
}
Flipping with this function will only allow one flip on each bit.