I read about bitwise operations a lot, but still, I couldn't give a meaning to this line.
((text.flags & ~Text.BOLD) & ~Text.ITALIC) | Text.BOLD | Text.ITALIC
It seems like the author is trying to be sure that this text doesn't have styles BOLD and ITALIC, and then he makes the text ITALIC and BOLD.
Am I right, or missing some detail?
It seems to be turning off all flags not BOLD and not ITALIC (via & with the complement), and then ensuring that BOLD | ITALIC is set (via |).
The end result would be that for any input text regardless of style, the output is text
Could be re-written as
int bold_italic = Text.BOLD | Text.ITALIC;
text.flags = (text.flags & ~bold_italic) | bold_italic;
No, you've got it; the & operations are erasing the BOLD and ITALIC bits, while the | operations set them.
Lets start with 4 bits flag.
BOLD = 0001; ITALIC = 0010
flags & ~BOLD =
flags & ~0001 =
flags & 1110 = clear BOLD flag.
flags | ITALIC =
flags | 0010 =
flags | 0010 = set ITALIC flag
Related
I have data as follows - please see the fiddle here for all data and code below:
INSERT INTO t VALUES
('|0|34| first zero'),
('|45|0| second zero'),
('|0|0| both zeroes');
I want to SELECT from the start of the line
1st character in the line is a piple (|)
next characters are a valid (possibly negative - one minus sign) INTEGER
after the valid INT, another pipe
then another valid INT
then a pipe
The rest of the line can be anything at all - including sequences with pipe, INT, pipe, INT - but these are not to be SELECTed!
and I'm using a regex to try and SELECT the valid INTEGERs. A single ZERO is also a valid reading - one ZERO and one ZERO only!
The valid integers must be from between the first 3 pipe (|) characters and not elsewhere in the line - i.e.
^|3|3|adfasfadf |555|6666| -- tuple (3, 3) is valid
but
^|--567|-765| adfasdf -- tuple (--567, -765) is invalid - two minus signs!
and
^|This is stuff.... |34|56| -- tuple (34, 56) is invalid - doesn't start pipe, int, pipe, int!
Now, my regexes (so far) are as follows:
SELECT
SUBSTRING(a, '^\|(0{1}|[-+]?[1-9]{1}\d*)\|') AS n1,
SUBSTRING(a, '^\|[-+]?[1-9]{1}\d*\|(0{1}|[-+]?[1-9]{1}\d*)\|') AS n2,
a
FROM t;
and the results I'm getting for my 3 records of interest are:
n1 n2 a
0 NULL |0|34| first zero -- don't want NULL, want 34
45 0 |45|0| second zero -- OK!
0 NULL |0|0| both zeroes -- don't want NULL, want 0
3 3 |3|3| some stuff here
...
... other data snipped - but working OK!
...
Now, the reason why it works for the middle one is that I have (0{1}|.... other parts of the regex in both the upper and lower one!
So, that means take 1 and only 1 zero OR... the other parts of the regex. Fine, I've got that much!
However, and this is the crux of my problem, when I try to change:
'^\|[-+]?[1-9]{1}\d*\|(0{1}|[-+]?[1-9]{1}\d*)\|'
to
'^\|0{1}|[-+]?[1-9]{1}\d*\|(0{1}|[-+]?[1-9]{1}\d*)\|'
Notice the 0{1}| bit I've added near the beginning of my regex - so, this should allow one and only one ZERO at the beginning of the second string (preceded by a pipe literal (|)) OR the rest... the pipe at the end of my 5 character snippet above in this case being part of the regex.
But the result I get is unchanged for the first 3 records - shown above, but it now messes up many records further down - one example a record like this:
|--567|-765|A test of bad negatives...
which obviously fails (NULL, NULL) in the first SELECT now returns (NULL,-765) for the second. If the first fails, I want the second to fail!
I'm at a loss to understand why adding 0{1}|... should have this effect, and I'm also at a loss to understand why my (0, NULL), (45, 0) and (0, NULL) don't give me (0, 0), (45, 0) and (0, 0) as I would expect?
The 0{1}| snippet appears to work fine in the capturing groups, but not outside - is this the problem? Is there a problem with PostgreSQL's regex implementation?
All I did was add a bit to the regex which said as well as what you've accepted before, please accept one and only one leading ZERO!
I have a feeling there's something about regexes I'm missing - so my question is as follows:
could I please receive an explanation as to what's going on with my regex at the moment?
could I please get a corrected regex that will work for INTEGERs as I've indicated. I know there are alternatives, but I'd like to get to the bottom of the mistake I'm making here and, finally
is there an optimum/best method to achieve what I want using regexes? This one was sort of cobbled together and then added to as further necessary conditions became clearer.
I would want any answer(s) to work with the fiddle I've supplied.
Should you require any further information, please don't hesitate to ask! This is not a simple "please give me a regex for INTs" question - my primary interest is in fixing this one to gain understanding!
Some simplifications could be done to the patterns.
SELECT
SUBSTRING(a, '^\|(0|[+-]?[1-9][0-9]*)\|[+-]?[0-9]+\|') AS n1,
SUBSTRING(a, '^\|[+-]?[0-9]+\|(0|[+-]?[1-9][0-9]*)\|') AS n2,
a
FROM t;
n1 | n2 | a
:--- | :--- | :--------------------------------------------------------------
0 | 34 | |0|34| first zero
45 | 0 | |45|0| second zero
0 | 0 | |0|0| both zeroes
3 | 3 | |3|3| some stuff here
null | null | |SE + 18.5D some other stuff
-567 | -765 | |-567|-765|A test of negatives...
null | null | |--567|-765|A test of bad negatives...
null | null | |000|00|A test of zeroes...
54 | 45 | |54|45| yet more stuff
32 | 23 | |32|23| yet more |78|78| stuff
null | null | |This is more text |11|111|22222||| and stuff |||||||
null | null | |1 1|1 1 1|22222|
null | null | |71253412|ahgsdfhgasfghasf
null | null | |aadfsd|34|Fails if first fails - deliberate - Unix philosophy!
db<>fiddle here
Here's a CFG that generates strings of 0s, 1s, or 0s and 1s arranged like this (001, 011) where one of the characters must have a bigger count than the other like in 00011111 or 00000111 for example.
S → 0S1 | 0A | 0 | 1B | 1
A → 0A | 0
B → 1B | 1
I tried converting it to regular expression using this guide but I got stuck here since I have trouble converting 0S1 given that anything similar to it can't be found in that guide.
S → 0S1 | 0+ | 0 | 1+ | 1
A → 0A | 0 = 0+
B → 1B | 1 = 1+
One of my previous attempts is 0+0+1|0+1+1|1+|0+ but it doesn't accept strings I mentioned above like 00011111 and 00000111.
Plug and Play
^(?!01$)(?!0011$)(?!000111$)(?!00001111$)(?=[01]{1,8}$)0*1*$
You cannot perfectly translate this to a regular expression, but you can get close, by ensuring that the input does not have equal number of 0 and 1. This matches up to 8 digits.
How it works
^ first you start from the beginning of a line
(?!01$) ensure that the characters are not 01
(?!0011$) ensure that the characters are not 0011
the same for 000111 and 00001111
then ensure that there are from 1 to 8 zeroes and ones (this is needed, to ensure that the input is not made of more digits like 000000111111, because their symmetry is not verified)
then match these zeroes and ones till the end of the line
for longer inputs you need to add more text, for up to 10 digits it is this: ^(?!01$)(?!0011$)(?!000111$)(?!00001111$)(?!0000011111$)(?=[01]{1,10}$)0*1*$ (you jump by 2 by adding one more symmetry validation)
it is not possible by other means with regular expressions alone, see the explanation.
Explanation
The A and B are easy, as you saw 0+ and 1+. The concatenations in S after the first also are easy: 00+, 0, 11+, 1, that all mixed into one lead to (0+|1+). The problem is with the first concatenation 0S1.
So the problem can be shorten to S = 0S1. This grammar is recursive. But neither left linear nor right linear. To recognize an input for this grammar you will need to "remember" how many 0 you found, to be able to match the same amount of 1, but the finite-state machines that are created from the regular grammars (often and from regular expressions) do not have a computation history. They are only states and transitions, and the machinery "jumps" from one state to the other and does not remember the "path" traveled over the transitions.
For this reason you need more powerful machinery (like the push-down automaton) that can be constructed from a context-free grammar (as yours).
I'm looking for an algorithm to convert a boolean expression tree into an optimal set of bitwise operations where the boolean inputs are indicated by bits in a word.
eg: suppose a set of bit flags like this:
enum
{
Apples = 1 << 0,
Pears = 1 << 1,
Bananas = 1 << 2,
}
and suppose an expression like this:
Apples && (Pears || Bananas)
has been parsed into an expression tree like this:
AND
|
+-- Apples
|
+-- OR
|
+-- Pears
|
+-- Bananas
How would one convert that AST to an optimal set of bitmask/test operations?
A general algorithm would be great, but in my use case most of the expressions are testing each bit as either set or clear and can be reduced to and bitwise test in the form ((input & mask) == test). eg:
Apples && Pears && !Bananas
can be evaluated as
(input & (Apples|Pears|Bananas)) == (Apples|Pears)
The only operators I need to support are boolean AND, OR and NOT.
I'll probably sit down and figure this out myself but thought it was an interesting problem that I've not seen discussed before. I'm wondering if there are existing solutions or if anyone has suggestions for how to approach it.
I figured this out and even wrote an .NET IL generator to generate code from the optimized execution plans. It's too much to explain here, but wrote an article about it.
Also, full code can be found here
I have to solve a question saying
The value of ab if ab & 0x3f equals 0x27.
For solving,I assumed let ab be 0xMN and then N&f means N&1111 but here book says that N&1111 should yield 0111 i.e. 7 =>N should be 7.
Similarly how M&0011should yield 2the book says without telling how.
This maybe quite a simple to you people but i tried didn't succeed so here.
Think of it this way - a bit can only have 2 possible values i.e. 0 or 1. If you write down the binary representations, you will end up with something like the below:
abcd efgh
& 0011 1111
-----------
= 0010 0111
Going by the definition of bitwise AND, the values of a to h that would give the below result are 0,0,1,0,0,1,1,1 respectively. Converting back to hexadecimal, the value is 0x27.
As #jlahd points out in the comments below, three more values can satisfy this equation : 0x67, 0xa7 and 0xe7. This is because x&0 = 0 so that a and b in the above could take any possible values without affecting the outcome.
I'm trying to include in my xslt for write byte 1 and write bye 3
as similarly we are doing for CR, LF, AMP ...like how can we write integer 1 in hexadecimal
it was not allowing me to do.
is allowing to do CR but it was not working �D; in xslt
similarly i have tried for to implement SOH as it was not working can any please ..help on this
i have tried a lot for to implement below task, can any suggest me it was helpful for me
Mnemonic Hex value Unicode Description
<SOH> X’01’ <U+0001> Start of Heading message
<ETX> X’03’ <U+0003> End of Text message
U+ 0 1 2 3
0000 NUL SOH STX ETX
0010 DLE DC1 DC2 DC3
0020 sp ! " #
0030 0 1 2 3
i am trying to implement SOH and ETX, you related code check you see above attached screen shot.
I guess this cannot be done; see extract from w3.org below: certain characters are not allowed.
Character Range
[2] Char ::= #x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] | [#x10000-#x10FFFF] /* any Unicode character, excluding the surrogate blocks, FFFE, and FFFF. */
Also see Things XSLT can't do - an oldie but probably still valid.