Recently while taking some algorithm practise at leetcode i came across a solution, i understood everything except the part where the user converts an element in a string to an integer, look at the code below. Hopefully someone can explain this to me. Thanks for replies in advnace.
a := 234
b := strconv.Itoa(a)
c := int(b[0]-48) // why do we subtract 48?
48 is the code of the '0' character in the ASCII table.
Go stores strings as their UTF-8 byte sequences in memory, which maps characters of the ASCII table one-to-one to their code.
The digits in the ASCII table are listed contiguously, '0' being 48. So if you have a digit in a string, and you subtract 48 from the character's code, you get the digit as a numeric value.
Indexing a string indexes its bytes, and in your case b[0] is the first byte of the b string, which is 2. And '2' - 48 is 2.
For example:
fmt.Println('0' - 48)
fmt.Println('1' - 48)
fmt.Println('2' - 48)
fmt.Println('3' - 48)
fmt.Println('4' - 48)
This outputs (try it on the Go Playground):
0
1
2
3
4
“b” is a string “234”, a string is a slice of rune therefore b[0] is a byte/rune, in this case a value of 50 which is the decimal value of a “2” in ascii. So “c” will be 50-48=2
Related
Can someone explain this behavior?
Buffer.from('5d9RAjZ2GCob-86_Ql', 'base64url').toString('base64url')
// 5d9RAjZ2GCob-86_Qg
Please take a close look at the last character l - g
Your string is 18 characters long, With 6 bits encoded in each character it means the first 16 characters represent 96 bits (12 bytes) and the last two represent one byte plus 4 unused bits. Only the first two bits of the last character are significant here. g is 100000, l is 100101. As the last 4 characters are not used, g is just the first choice for the two bits 1 0.
So for any character in the range between g and v, you would get a g when you convert it back to Base64Url.
See https://en.wikipedia.org/wiki/Base64#Base64_table_from_RFC_4648
I need some help understanding this concept:
If I have a 256-bit hash, the value is essentially a 64-character long string. This is because each character is 4-bits long (64*4 = 256), correct? However, along with numbers letters are also used in hash values, and letters are 8-bits long. Doesn't a 64-character long hash key that features letters along with numbers ultimately create a hash value that is greater than 256-bits?
Take this hash value for example: 7833dc6e82e9378117bcb03128ac8fdd95d9073161ebc963783b3010dd847ff3
It is 64-characters long, but the letter d is 8-bits long rather than 4. So how does this hash count as 256-bits?
Thank you for your help!
The letters aren't really letters. You've probably noticed that the only included alphabet characters are A-F. This is because the hash is using base 16 (hexadecimal) numbering.
Unlike base 10 where the valid characters are 0-9, in base 16, there are sixteen valid characters: 0 1 2 3 4 5 6 7 8 9 A B C D E F. 16 = 2^4, so you need 4 bits for each character.
In matlab, how can I turn a string or cell of digits into a vector of numbers, where each digit in the string is an element in the vector.
That is, for eg., how to turn this:
A=3141592;
(where class(A)=char)
into this:
A=[3 1 4 1 5 9 2];
(where class(A)=double)
This is related to this question
Subtract ascii value of '0' from each of the ascii characters that constitute the string in A to get the double array -
A-'0'
Straight away plugging in the ascii value would work too -
A-48
Output -
ans =
3 1 4 1 5 9 2
I am attempting to format a string in such a way, that I can make a repeating sequence of numbers an arbitrary length.
I've been looking at these examples: How do I format a number with a variable number of digits in Python? and String Formatting in Python 3.
Here's what I tried to do:
print("{0:{1}{2}d}".format(0, 0, 8))
will result in eight pretty 0's all in a row like so: 00000000
but attempting to change the second argument from 0 to 25
print("{0:{1}{2}d}".format(0, 25, 8))
Results in an a single 0 that is as far right as it can go in my console instead of 25252525 So I think the issue is using a string with more than one character as filler instead of a single character.
The specification for string formatting goes like this:
format_spec ::= [[fill]align][sign][#][0][width][,][.precision][type]
In this case, we're only interested in the [0][width] part. [0] is an optional parameter which pads numbers with zeros, so you can format 4 as '004'. [width] specifies the total width of the field.
When you write:
print("{0:{1}{2}d}".format(0, 0, 8))
It becomes:
print("{0:08d}".format(0))
Which is a 0 padded with zeroes up to a length of 8: 00000000.
However, your other example:
print("{0:{1}{2}d}".format(0, 25, 8))
Becomes:
print("{0:258d}".format(0))
Which is a 0 padded with spaces (because there is no 0 in the formatter) up to a length of 258.
I think string formatting is not suited to solve your problem. You can use other fill characters than 0 (using the [fill] option in the formatting spec), but it can't be more than one character.
The simplest way to get what you want is probably this:
>>> print((str(25) * 8)[:8])
25252525
Question:
Is it save to get substring n characters from a text in RPG using MOVEL function which take a text with length x and store it to a variable with capacity n?
Or the only save way to get the first n character is using SUBST?
The background of the question is one of my colleague getting the first 3 characters from a database with 30 char in length is using MOVEL to a variable with length only 3 char (like truncating the rest of it). The strange way, sometimes the receive variable is showing minus character ('-'), sometimes doesn't. So I assume using MOVEL is not a safe way. I am thinking like string in C which always terminated by '\0', you need to use strcpy function to get the copy save, not assigning using = operator.
Anybody who knows RPG familiar with this issue?
MOVEL should work. RPG allows several character data types. Generally speaking, someone using MOVEL will not be dealing with null terminated strings because MOVEL is an old technique and null terminated strings are a newer data type. You can read up on the MOVEx operations and the string operations in the RPG manual. To get a better answer, please post your code, including the definitions of the variables involved.
EDIT: Example of how MOVEL handles signs.
dcl-s long char(20) inz('CORPORATION');
dcl-s short char(3) inz('COR');
dcl-s numb packed(3: 0);
// 369
c movel long numb
dsply numb;
// -369
c movel short numb
dsply numb;
*inlr = *on;
With signed numeric fields in RPG the sign is held in the zone of the last byte of the field. So 123 is X'F1F2F3' but -123 is X'F1F2D3'. If you look at those fields as character strings they will have 123 and 12L in them.
In your program you are transferring something like "123 AAAAAL" to a 3 digit numeric field so you get X'F1F2F3' but because the final character is X'D3' that changes the result to have a zone of D i.e. X'F1F2D3'
You anomaly is dependent on what the 30th character contains. If it is } or any capital letter J to R then you get a negative result. [It doesn't matter whether the first 3 characters are numbers or letters because it is only the second half of the byte, the digit, that matters in your example.]
The IBM manuals say:
If factor 2 is character and the result field is numeric, a minus zone is moved into the rightmost position of the result field if the zone from the rightmost position of factor 2 is a hexadecimal D (minus zone). However, if the zone from the rightmost position of factor 2 is not a hexadecimal D, a positive zone is moved into the rightmost position of the result field. Other result field positions contain only numeric characters.
Don