We Keep Coding

Understanding Cyclic Redundancy Code algorithm for beginners

at section 5.5 of the PNG Specification, it discusses this concept in the PNG file format called "CRC" or "Cyclic Redundancy Code". I've never heard of it before, so I'm trying to understand it.
The CRC polynomial employed is
x32 + x26 + x23 + x22 + x16 + x12 + x11 + x10 + x8 + x7 + x5 + x4 + x2
+ x + 1
In PNG, the 32-bit CRC is initialized to all 1's, and then the data
from each byte is processed from the least significant bit (1) to the
most significant bit (128). After all the data bytes are processed,
the CRC is inverted (its ones complement is taken). This value is
transmitted (stored in the datastream) MSB first. For the purpose of
separating into bytes and ordering, the least significant bit of the
32-bit CRC is defined to be the coefficient of the x31 term.
So let me tell you what I understand and what I don't understand about this.
I've heard of polynomials, but in this context I'm a bit confused of how they are implemented here.
In this case, what is "x" supposed to represent? The current bit in the 32-bit looP? Which brings us to the next part:
so it says to make an empty 32-bit number (or rather, all set to 1s, so 32 1s), then it says it's "processed from the least significant bit (1) to the most significant bit (128)", but the question is, the "least...most..significant bit" of what?
Of the other data in the chunk?
How does that work, if the chunk is set in bytes, and this is only 32 bits? What if there are more than 32 bits in the chunk data (which there definitely are?)
Does it mean "least..most..significant bit" of the "polynomial"?
But what does the polynomial represent exactly? What is x^32?
What is x represented by?
Any help with the above questions, and perhaps a simple example with the example IDATA chunk (AKA calculating the CRC chunk for it with basic explanations) would be great:
0 0 2 3 IDAT 0 1 0 1 0 1 0 1 0 1 0 C
where the last byte "C" should be replaced with that 32-bit CRC thing it was talking about.
Can someone provide me with a practical example?

I would recommend reading Ross Williams' classic "A Painless Guide to CRC Error Detection Algorithms". Therein you will find in-depth explanations and examples.
The polynomial is simply a different way to interpret a string of bits. When you have n bits in a register, they are most commonly interpreted either as just that, a list of n independent bits, or they are interpreted as an integer, where you multiply each bit by two raised to the powers 0 to n-1 and add them up. The polynomial representation is where you instead interpret each bit as the coefficient of a polynomial. Since a bit can only be a 0 or a 1, the resulting polynomials never actually show the 0 or 1. Instead the xn term is either there or not. So the four bits 1011 can be interpreted to be 1 x3 + 0 x2 + 1 x1 + 1 x0 = x3 + x + 1. Note that I made the choice that the most significant bit was the coefficient of the x3 term. That is an arbitrary choice, where I could have chosen the other direction.
As for what x is, it is simply a placeholder for the coefficient and the power of x. You never set x to some value, nor determine anything about x. What it does is allow you to operate on those bit strings as polynomials. When doing operations on these polynomials, you treat them just like the polynomials you had in algebra class, except that the coefficients are constrained to the field GF(2), where the coefficients can only be 0 or 1. Multiplication becomes the and operation, and addition becomes the exclusive-or operation. So 1 plus 1 is 0. You get a new and different way to add, multiply, and divide strings of bits. That different way is key to many error detection and correction schemes.
It is interesting, but ultimately irrelevant, that if you set x to 2 in the polynomial representation of a string of bits (with the proper ordering choice), you get the integer interpretation of that string of bits.

The spec includes a link to example code:
https://www.w3.org/TR/2003/REC-PNG-20031110/#D-CRCAppendix
The spec has errors or is confusing.
That should be "data from each byte is processed from the least significant bit(0) to the most significant bit bit(7).
The CRC is a 33 term polynomial, where each term has a one bit coefficient, 0 or 1, with the 0 coefficients ignored when describing the polynomial.
Think of the CRC as being held in a 32 bit register. The sequence is to xor a byte of data into the right most byte of the CRC register, bits 7 through 0 (which technically correspond to the polynomial coefficients of x^24 to x^31). Then the CRC is "cycled" to the right for 8 bits (via table lookup). Once all data bytes have gone through this cycle, based on the comment from Mark Adler, it's the CRC is appended to data most significant byte first, (CRC>>24)&0xff, (CRC>>16)&0xff, (CRC>>8)&0xff, (CRC)&0xff.
The wiki article may help. For the example in the computation section, the dividend would be an array of data bytes with the bits of each byte reversed, the bits of the 33 bit polynomial would be non-reversed (0x104C11DB7). After doing the computation, the bits of the remainder would be reversed and appended to the data bytes.
https://en.wikipedia.org/wiki/Cyclic_redundancy_check
Mark Adler's answer includes a link to a good tutorial for a CRC. His answer also explains the x's used in a polynomial. It's just like a polynomial in algebra, except the coefficients can only be 0 or 1, and addition (or subtraction) is done using XOR.
what is x
From the wiki example:
data = 11010011101100 = x^13 + x^12 + x^10 + x^7 + x^6 + x^5 + x^3 + x^2
divisor = 1011 = x^3 + x + 1
Three 0 bits are appended to the data, effectively multiplying it by x^3:
dividend = 11010011101100000 = x^16 + x^15 + x^13 + x^10 + x^9 + x^8 + x^6 + x^5
Then the crc = dividend % divisor, with coefficients restricted to 0 or 1.
(x^16 + x^15 + x^13 + x^10 + x^9 + x^8 + x^6 + x^5) % (x^3 + x + 1) = x^2
11010011101100000 % 1011 = 100

Beware: If you use (00000000)_2 and (00000001)_2 as the binary representations of the 0s and 1s in your example IDAT chunk, you will compute the CRC incorrectly. The ASCII values of '0' and '1' are 48 = (00110000)_2 and 49 = (00110001)_2; similarly, the ASCII values of 'I', 'D', 'A', and 'T' are 73 = (01001001)_2, 68 = (01000100)_2, 65 = (01000001)_2, and 84 = (01010100)_2. So, assuming you meant the values 0 and 1 rather than the characters ‘0’ and ‘1’, what you must compute the CRC of is (01001001 01000100 01000001 01010100 00000000 00000001 00000000 00000001 00000000 00000001 00000000 00000001 00000000 00000001 00000000)_2.
Inconsequentially to the CRC but consequentially to the validity of the chunk, the length field (i.e., the first 4 bytes) of the chunk should contain the length in bytes of the data only, which is 11, which is the ASCII value of a vertical tab (VT), which is a nonprinting character but can be represented in strings by the hexadecimal escape sequence \x0B (in which (B)_16 = 11). Similarly, the first 3 bytes must contain the character for which the ASCII value is 0 (rather than 48), which is null (NUL), which can be represented in strings by the hexadecimal escape sequence \x00. So, the length field must contain something like "\x00\x00\x00\x0B".

Which takes less memory in MongoDB, a number or a string?

I'm trying to make my database as efficient as possible. It's a really simple database in which the collections only have documents that store either strings, or numbers or booleans. No arrays, mixed data types etc. If I want to store 24 as the value of one of the fields (which will only contain natural numbers). Which would take less space
{
field: 24
}
or
{
field: "24"
}
I'm using mongoose, and what I'm basically asking is that should I set Number or String as the type in my Schema for that particular field.

Store numbers as Numbers.
MongoDB uses BSON (spec). Number in this context usually means a 64-bit IEEE-754 floating-point number (what BSON calls a double), so that's going to take...64 bits. :-) Add to that the overhead (according to the spec) of saying it's a number (one byte) and the field name (the length of the name plus one byte), but as those will be the same for Number and String we can disregard them. So 64 bits for Number.
The spec says String is stored as a 32-bit length followed by the string in UTF-8 followed by a terminator byte (plus the overhead in common with Number). That's 32 + (8 x number_of_bytes_in_utf_8) + 8 bits for a string.
Each of the characters used to represent numbers in strings (-, +, 0-9, e/E [for scientific notation], and .) are represented with a single byte in UTF-8, so for our purposes in this question, # of chars = # of bytes.
So:
For "24" it's 32 + (8 x 2) + 8 giving us 56 bits.
For "254" it's 32 + (8 x 3) + 8 giving us 64 bits.
For "2254" it's 32 + (8 x 4) + 8 giving us 72 bits.
For "1.334" it's 32 + (8 x 5) + 8 giving us 80 bits.
See where I'm going with this? :-)
Add to that the fact that if it's a number, then storing it as a string:
...imposes a runtime penalty (converting to and fron string)
...means you can't do range comparisons like Ali Dehghani's {$gt: {age: "25"}} example
...and I'd say Number is your clear choice.

What is the use of "|" (pipe) symbol in a JS array

I have a JS array which is being used as follows in our existing code:
temp = charArray[0 | Math.random() * 26];
Wanted to know what exactly is the usage of "|" symbol in the above code and are there more such operators?

From the MDN:
Bitwise operators treat their operands as a set of 32 bits (zeros and
ones) and return standard JavaScript numerical values.
As the 32 bit part is (a part of) the integer part of the IEEE754 representation of the number, this is just a trick to remove the non integer part of the number (be careful that it also breaks big integers not fitting in 32 bits!).
It's equivalent to
temp = charArray[Math.floor(Math.random() * 26)];

| is bitwise OR, which means, that all bits that are 1 in either of the arguments will be 1 in the result. A bitwise OR with 0 returns the given input interpreted as an integer.
In your code the its majorily used to convert the
Math.random()
number to integer. The bottom line is :
var a = 5.6 | 0 //a=5
Explanation:
Lets take
var a = 5; //binary - 101
var b = 6; //binary - 110
a|b a|a a|0
101 101 101
110 101 000
------ ------ ------
111-->7 101-->5 101-->5

Why 0010 in javascript is equal to 8?

i wrote from 001 to 0010 and much more digit like this that started with "00" in chrome console and Fire Fox even in IE and get this result.
why 0010 is not equal to 10 ?
or why 0020 is not equal to 20 ? and it is "16".

A leading zero indicates that a number should be interpreted as octal.
Thus 10 interpreted as octal is equal to 8 in decimal.
For more information refer to MDN on number literals.

"Numeric constants are considered octal if they are preceded by a zero, and are considered hexadecimal if they are preceded by a zero and and x (0x)." (as explained here)
008 is not considered octal because it contains "8" which is not an octal number. 0010 is in fact an octal number and equals 8.

Number literals in Javascript can be entered in different bases -
a leading zero means the number is the number is in octal base (only digits 0-7) so 010 is the same as: one times 8 + zero
the literal 0x10 is in hexadecimal (base 16) so equals to: one times 16 + zero) = 16
see here https://developer.mozilla.org/en/docs/JavaScript/Guide/Values,_variables,_and_literals

Because the leading 0 represents an Octal number system. Likewise, if you had typed 0x010 it would equal to 16, since 0x is prefix for Hexadecimal number system.

Javascript. | & and toString

var ddd = Math.random() * 16;
console.log((ddd & 3 | 8).toString(16));
Help me please. I dont understand how works this operators (| and &) and why this code returns a-f symbols?

The expression ddd & 2 | 8 is doing bitwise arithmetic by taking the bitwise OR operation of 8 and the bitwise AND operation of ddd and 2. If you don;t understand bitwise operations, you should consult this article explaining what they are.
The code can return characters in the range a-f because you passed in a radix parameter 16 to the Number.toString prototype method, which means that it will display the number in hexadecimal.

This picks a random real number from 0 to 15:
var ddd = Math.random() * 16;
For example, you might get 11.114714370026688.
ddd & 3
That's a bitwise AND of the result with the number 3. The first thing that does is take the number from ddd and convert it to an integer, because the bitwise operators aren't defined for floating point numbers. So in my example, it treats ddd as the whole number 11.
The next thing it does is perform an AND of the two numbers' binary representations. Eleven in binary is 1011 and three is 0011. When you AND them together, you get a binary number that is all zeroes except where there's a 1 in both numbers. Only the last two digits have 1's in both numbers, so the result is 0011, which is again equal to decimal 3.
| 8
That does a bitwise OR of the result so far (3) with the number 8. OR is similar to AND, but the result has 1's wherever there's a 1 in either number. Since three is still 0011 in binary and eight is 1000, the result is 1011 - which is back to decimal eleven.
In general, the above calculation sets the 8-bit (third from the right) to 1 and the 4-bit (second from the right) to 0, while leaving the other bits alone. The end result is to take your original random number, which was in the range 0-15, and turn it into one of only four numbers: 8, 9, 10, or 11. So it's a very roundabout way of generating a random number between 8 and 11, inclusive. Math.floor(8 + Math.random()*4) would have done the same thing in a more straightforward manner.
It then prints the result out in hexadecimal (base 16), so you get 8, 9, a (which is ten in base 16), or b (which is eleven).