How should I do a hexademical calculation in OCaml?
For example I want to multiply 0x0a and 0xff.
What should I do?
0x0a * 0xff
Hexadecimal is just yet another notation, not another algebra.
For the whole package, use Printf.printf "%x\n" (0x0a * 0xff).
The %x conversion prints in hexadecimal, and integer constants in the program can be typed in hexadecimal with the 0x prefix.
Example:
$ rlwrap ocaml
OCaml version 4.01.0
# Printf.printf "0x%x\n" (0x0a * 0xff);;
0x9f6
Related
The 'xor'-operator in julia is defined by the following symbol: ⊻
If I am not mistaken this is also the only symbol representing 'xor'.
How are you supposed to type this conveniently?
Am I supposed to copy or paste it into my code or remember the unicode representation by heart?
Julia's REPL has LaTeX-like tab-completion, so you can use \xor<tab>. If you paste the character in the help mode (pressing ? in the REPL) you can see how such character tab-completes:
help?> ⊻
"⊻" can be typed by \xor<tab>
help?> α
"α" can be typed by \alpha<tab>
Many editors have similar tab-completions.
I was wondering how to do encoding and decoding in R. In Python, we can use ord('a') and chr(97) to transform a letter to number or transform a number to a letter. Do you know any similar functions in R? Thank you!
For example, in python
>>>ord("a")
97
>>>ord("A")
65
>>>chr(97)
'a'
>>>chr(90)
'Z'
FYI:
ord(c) in Python
Given a string of length one, return an integer representing the Unicode code point of the character when the argument is a unicode object, or the value of the byte when the argument is an 8-bit string. For example, ord('a') returns the integer 97, ord(u'\u2020') returns 8224. This is the inverse of chr() for 8-bit strings and of unichr() for unicode objects. If a unicode argument is given and Python was built with UCS2 Unicode, then the character’s code point must be in the range [0..65535] inclusive; otherwise the string length is two, and a TypeError will be raised.
chr(i) in Python
Return a string of one character whose ASCII code is the integer i. For example, chr(97) returns the string 'a'. This is the inverse of ord(). The argument must be in the range [0..255], inclusive; ValueError will be raised if i is outside that range. See also unichr().
You're looking for utf8ToInt and intToUtf8
utf8ToInt("a")
[1] 97
intToUtf8(97)
[1] "a"
This is from the online Ada reference manual:
http://www.adaic.org/resources/add_content/standards/05rm/RM.pdf (section 2.3)
A decimal_literal is a numeric_literal in the conventional decimal notation (that is, the base is ten).
Syntax
decimal_literal ::= numeral [.numeral] [exponent]
**numeral ::= digit {[underline] digit}**
exponent ::= E [+] numeral | E – numeral
digit ::= 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9
An exponent for an integer literal shall not have a minus sign.
Static Semantics
**An underline character in a numeric_literal does not affect its meaning.** The letter E of an exponent can be
written either in lower case or in upper case, with the same meaning.
If I do
my_literal ::= 123_456;
what does the underscore (underline) mean? It says it doesn't affect the meaning. Then what is it for? I am sure there is a simple answer but reading and re-reaidng the passage hasn't helped me.
It's the same reason for, say, commas (,) in currency or [other large] numbers: grouping.
Thus:
Million : Constant:= 1_000_000;
Furthermore, you could use it in conjunction with base-setting as a set-up for masking:
Type Bit is Range 1..8;
SubType Byte is Interfaces.Unsigned_8;
Type Masks is Array(Positive Range <>) of Byte;
Mask_Map : Constant Masks(Bit):=
(
2#0000_0001#,
2#0000_0010#,
2#0000_0100#,
2#0000_1000#,
2#0001_0000#,
2#0010_0000#,
2#0100_0000#,
2#1000_0000#
);
Then perhaps you would use Mask_Map and bits together with or, and, and xor to do bit-manipulation. The above method may seem a bit more work than the simple definition of a lot of constants and directly manipulating them, but it is more flexible in that you can later change it into a function and not have to change any client-code, that could further be useful if that function's result was a parametrized integer, where bit has the definition 1..PARAMETER'Size.
What is the cause of certain characters to be blank when using XOR encryption? Furthermore, how can this be compensated for when decrypting?
For instance:
....
void basic_encrypt(char *to_encrypt) {
char c;
while (*to_encrypt) {
*to_encrypt = *to_encrypt ^ 20;
to_encrypt++;
}
}
will return "nothing" for the character k. Clearly, character decay is problematic for decryption.
I assume this is caused by the bit operator, but I am not very good with binary so I was wondering if anyone could explain.
Is it converting an element, k, in this case, to some spaceless ASCII character? Can this be compensated for by choosing some y < x < z operator where x is the operator?
Lastly, if it hasn't been compensated for, is there a realistic decryption strategy for filling in blanks besides guess and check?
'k' has the ASCII value 107 = 0x6B. 20 is 0x14, so
'k' ^ 20 == 0x7F == 127
if your character set is ASCII compatible. 127 is \DEL in ASCII, which is a non-printable character, so won't be displayed if you print it out.
You will have to know the difference between bytes and characters to understand which is happening. On the one hand you have the C char type, which is simply a presentation of a byte, not a character.
In the old days each character was mapped to one byte or octet value in a character encoding table, or code page. Nowadays we have encodings that take more bytes for certain characters, e.g. UTF-8, or even encodings that always take more than one byte such as UTF-16. The last two are unicode encodings, which means that each character has a certain number value and the encoding is used to encode this number into bytes.
Many computers will interpret bytes in ISO/IEC 8859-1 or Latin-1, sometimes extended by Windows-1252. These code pages have holes for control characters, or byte values that are simply not used. Now it depends on the runtime system how these values are handled. Java by default substitutes an ? character in place of the missing character. Other runtimes will simply drop the value or - of course - execute the control code. Some terminals may use the ESC control code to set the color or to switch to another code page (making a mess of the screen).
This is why ciphertext should be converted to another encoding, such as hexadecimals or Base64. These encodings should make sure that the result is readable text. This takes care of the cipher text. You will have to choose a character set for your plain text too, e.g. simply perform ASCII or UTF-8 encoding before encryption.
Getting a zero value from encryption does not matter because once you re-xor with the same xor key you get the original value.
value == value
value XOR value == 0 [encryption]
( value XOR value ) XOR value == value [decryption]
If you're using a zero-terminated string mechanism, then you have two main strategies for preventing 'character degradation'
store the length of the string before encryption and make sure to decrypt at least that number of characters on decryption
check for a zero character after decoding the character
The Tcl expr function supports arguments written in hex notation: operands which begin with 0x are treated as integers written in hex form.
However the return value of expr is always in decimal form: expr 0xA + 0xA returns 20, not 0x14.
Is there a way to tell expr to return the hex representation?
Is there a Tcl function which converts decimal representation to hex?
the format command is what you're after:
format 0x%x [expr {0xa + 0xa}] ;# ==> 0x14
I'd like to elaborate on the glenn's post to make things more clear for Vahagn.
expr does not return its result in one representation or another, instead, it returns a value in some suitable internal format (an integer, a big integer, a floating point value etc). What you see doing your testing is just Tcl interpreter converting what expr returned to an appropriate textual form using a default conversion to a string which, for integers, naturally uses base 10.
This conversion takes place in your case solely because you wanted to display the value returned by expr, and displaying of (any) values naturally tends to convert them to strings if they are "printed"—to a terminal, to a tkcon's window etc.
By using format you enforce whatever string representation you want instead of the default one. Since format already returns a value which is a string internally, no conversion takes place when it's printed.