Update

acronym.md

@@ -107,6 +107,7 @@ Here is a list of some acronyms:
 - **[FPS](fps.md)** (frames per second, first person shooter)
 - **[FQA](fqa.md)** (frequently questioned answers)
 - **[FS](fs.md)** (file system)
+- **[FTL](ftl.md)** (faster than light)
 - **[FTP](ftp.md)** (file transfer protocol)
 - **[FU](fu.md)** (fuck you)
 - **[FXAA](fxaa.md)** (full screen anti aliasing)

compression.md

@@ -1,6 +1,6 @@
 # Compression
 
-Compression means encoding [data](data.md) (such as images or texts) in a different way so that it takes less storage memory while keeping all the important [information](information.md), or, in plain terms, it usually means "making files smaller". Compression is pretty important so that we can utilize memory well -- without it our hard drives would be able to store just a handful of videos, internet would be slow as hell due to the gigantic amount of transferred data and our [RAM](ram.md) wouldn't suffice for things we normally do. There are many [algorithms](algorithm.md) for compressing various kinds of data, differing by their complexity, performance, efficiency of compression etc. The reverse process to compression (getting the original data back from the compressed data) is called **decompression**. The ratio of the compressed data size to the original data size is called **compression ratio** (the lower, the better). The science of data compression is truly huge and complicated AF, here we'll just mention some very basics.
+Compression means encoding [data](data.md) (such as images or texts) in a different way so that the data takes less space (memory) while keeping all the important [information](information.md), or, in plain terms, it usually means "making files smaller". Compression is pretty important so that we can utilize memory or bandwidth well -- without it our hard drives would be able to store just a handful of videos, internet would be slow as hell due to the gigantic amount of transferred data and our [RAM](ram.md) wouldn't suffice for things we normally do. There are many [algorithms](algorithm.md) for compressing various kinds of data, differing by their complexity, performance, efficiency of compression etc. The reverse process to compression (getting the original data back from the compressed data) is called **decompression**. The ratio of the compressed data size to the original data size is called **compression ratio** (the lower, the better). The science of data compression is truly huge and complicated AF, here we'll just mention some very basics. Also watch out: compression algorithms are often a [patent](patent.md) mine field.
 
 { There is a cool compressing competition known as Hutter Prize that offers 500000 pounds to anyone who can break the current record for compressing [Wikipedia](wikipedia.md). Currently the record is at compressing 1GB down to 115MB. See http://prize.hutter1.net for more. ~drummyfish }
 
@@ -33,7 +33,61 @@ Mathematically there cannot exist a lossless compression algorithm that would al
 
 ## Methods
 
-TODO
+The following is an overview of some most common compression techniques.
+
+### Lossless
+
+**[RLE](rle.md) (run length encoding)** is a simple method that stores repeated sequences just as one element of the sequence and number of repetitions, i.e. for example *"abcabcabc"* as *"3abc"*.
+
+**[Entropy](entropy.md) coding** is another common technique which counts the frequencies ([probabilities](probability.md)) of symbols on the input and then assigns the shortest codes to the most frequent symbols, leaving longer codes to the less frequent. The most common such codings are **[Huffman coding](huffman_coding.md)** and **[Arithmetic coding](arithmetic_coding.md)**.
+
+**Dictionary (substitutional) methods** try to construct a dictionary of relatively long symbols appearing in the input and then only store short references to these symbols. The format may for example choose to first store the dictionary and then the actual data with pointers to this dictionary, or it may just store the data in which pointers are stored to previously appearing sequences.
+
+**[Predictor](predictor.md) compression** is based on making a *predictor* that tries to guess following data from previous values (which can be done e.g. in case of pictures, sound or text) and then only storing the difference against such a predicted result. If the predictor is good, we may only store the small amount of the errors it makes.
+
+An approach similar to the predictor may be trying to find some general mathematical [model](model.md) of the data and then just find and store the right parameters of the model. This may for example mean [vectorizing](vector_graphics.md) a bitmap image, i.e. finding geometrical shapes in an image composed of pixels and then only storing the parameters of the shapes -- of course this may not be 100% accurate, but again if we want to preserve the data accurately, we may additionally also store the small amount of errors the model makes. Similar approach is used in [vocoders](vocoder.md) used in cellphones that try to mathematically model human speech (however here the compression is lossy), or in [fractal](fractal.md) compression of images. A nice feature we gain here is the ability to actually "increase the resolution" (or rather generate detail) of the original data -- once we fit a model onto our data, we may use it to tell us values that are not actually present in the data (i.e. we get a fancy [interpolation](interpotation.md)/[extrapolation](extrapolation.md)).
+
+Another property of data to exploit may be its sparsity -- if for example we have a huge image that's prevalently white, we may say white is the implicit color and we only somehow store the pixels of other colors.
+
+Some more wild techniques may include [genetic programming](genetic_programming.md) that tries to evolve a small program that reproduces the input data, or using "[AI](ai.md)" in whatever way to compress the data.
+
+Note that many of these methods may be **combined or applied repeatedly** as long as we are getting smaller results.
+
+Furthermore also take a look at [procedural generation](procgen.md), a related technique that allows to embed a practically infinite amount of content with only quite small amount of code.
+
+### Lossy
+
+In lossy compression we generally try to limit information that is not very important and/or to which we aren't very sensitive, typically by dropping precision by [quantization](quantization.md), i.e. basically lowering the number of bits we use to store the "not so important" information -- in some cases we may just drop some information altogether (decrease precision to zero). Furthermore we finally also apply lossless compression to make the result even smaller.
+
+For **images** we usually exploit the fact that human sight is less sensitive to certain visual information, such as specific frequencies, colors, brightness etc. Common methods used here are:
+
+- Convert image from [RGB](rgb.md) to [YUV](yuv.md), leave the Y channel (brightness) as is and reduce resolution of the U an V (color) channels. This works because human eye is less sensitive to color than brightness.
+- Convert the image to frequency domain (e.g. with [DCT](dct.md) or some [wavelet transform](wavelet_transform.md)) and quantize (allocate fewer bits to) higher frequencies. This exploits the fact that human eye is less sensitive to higher frequencies. This is the basis of e.g. [jpeg](jpg.md).
+- Reduce the number of possible colors -- traditional RGB uses 8 bits for each R, G and B component and so each pixel takes 3 bytes, which allows for about 6 million colors. However using just 2 bytes (65 thousand colors) many times [suffices](good_enough.md) and saves 1/3rd of the size -- see [RGB565](rgb565.md). We may also utilize an image-specific [palette](palette.md) and save the image in indexed mode, i.e. compute a palette of let's say 256 most common colors in the image, then encode the image as the palette plus pixels, of which each will only take one byte! This saves almost 2/3rds of the size. The drop of quality can further be made less noticeable with [dithering](dithering.md).
+- Reduce resolution -- plain simple. However this can be made smarter by e.g. trying to detect areas with few details and only reducing the resolution there.
+
+In **video** compression we may reuse the ideas from image compression and further employ exploiting temporal redundancy, i.e. the fact that consecutive video frames look similar, so we may only encode some kind of delta (change) against the previous (or even next) frame. The most common way is to fully record only one key frame in some time span (so called I-frame, further compressed with image compression methods), then divide it to small blocks and estimate the movement of those blocks so that they approximately make up the following frames -- we then record only the motion vectors of the blocks. This is why videos look "blocky". In the past [interlacing](interlacing.md) was also used -- only half of each frame was recorded, every other row was dropped; when playing, the frame was interlaced with the previous frame.
+
+In **audio** we usually straight remove frequencies that humans can't hear (usually said to be above 20 kHz), for this we again convert the audio from spatial to frequency domain (using e.g. [Fourier transform](fourier_transform.md)). Furthermore it is very inefficient to store sample values directly -- we rather use so called *differential PCM*, a lossless compression that e.g. stores each sample as a difference against the previous sample (which is usually small and doesn't use up many bits). This can be improved by a predictor, which tries to predict the next values from previous values and then we only save the difference against this prediction. *Joint stereo coding* exploits the fact that human hearing is not so sensitive to the direction of the sound and so e.g. instead of recording both left and right stereo channels in full quality rather records the sum of both and a ratio between them (which can get away with fewer bits). *Psychoacoustics* studies how humans perceive sound, for example so called *masking*: certain frequencies may for example mask nearby (both in frequency and time) frequencies (make them unhearable for humans) so we can drop them. See also [vocoders](vocoder.md).
+
+## Compression Programs/Utils/Standards
+
+Here is a list of some common compression programs/utilities/standards/formats/etc:
+
+| util/format       | extensions | free? | media        | lossless? | notes                                        |
+| ----------------- | ---------- | ----- | -------------| --------- | -------------------------------------------- |
+|[bzip2](bzip2.md)  | .bz2       | yes   | general      | yes       | Burrows–Wheeler alg.                         |
+|[flac](flac.md)    | .flac      | yes   | audio        | yes       | super free lossless audio format             |
+|[gif](gif.md)      | .gif       |now yes| image/anim.  | no        | limited color palette, patents expired       |
+|[gzip](gzip.md)    | .gz        | yes   | general      | yes       | by GNU, DEFLATE, LZ77, mostly used by Unices |
+|[jpeg](jpeg.md)    | .jpg, .jpeg| yes?  | raster image | no        | common lossy format, under patent fire       |
+|[lz4](lz4.md)      | .lz4       | yes   | general      | yes       | high compression/decompression speed, LZ77   |
+|[mp3](mp3.md)      | .mp3       |now yes| audio        | no        | popular audio format, patents expired        |
+|[png](png.md)      | .png       | yes   | raster image | yes       | popular lossless image format, transparency  |
+|[rar](rar.md)      | .rar       | NO    | general      | yes       | popular among normies, PROPRIETARY           |
+|[vorbis](vorbis.md)| .ogg       | yes   | audio        | no        | was a free alternative to mp3, used with ogg |
+|[zip](zip.md)      | .zip       | yes?  | general      | yes       | along with encryption may be patented        |
+|[7-zip](7zip.md)   | .7z        | yes   | general      | yes       | more complex archiver                        |
 
 ## Code Example
 

entropy.md

@@ -1,9 +1,31 @@
 # Entropy
 
-TODO
+Entropy is a quite cryptic, often misunderstood scientific term that may have different definitions depending on specific field and context, which can intuitively be interpreted as an amount of disorder, uncertainty or [randomness](randomness.md). There are two main kinds of entropy: information entropy (information theory) and thermodynamic entropy (physics).
 
 ## Information Entropy
 
+Information entropy is a basic concept in [information theory](information_theory.md) -- watch out, this kind of entropy is different from entropy in physics (which is described below). We use entropy to express an "amount of hidden information" in events, messages, codes etc. This can be used e.g. to design [compression](compression.md) algorithms, help utilize bandwidths better etc.
+
+Let's first define what information means in this context (note that the meaning of *information* here is kind of mathematical, not exactly equal to the meaning of *information* used in common speech). For a random event (such as a coin toss) with probability *p* the amount of information we get by observing it is
+
+*I(p) = log2(1/p) = -1 * log2(p)*
+
+The unit of information here is [bit](bit.md) (note the base 2 of the logarithm -- other bases can be used too but then the units are called differently), in information theory also known as *shannon*. Let's see how the definition behaves: the less probable an event is, the more information its observation gives us (with 0, i.e. impossible event, theoretically giving infinite information), while probability 1 gives zero information (observing something we know will happen tells us literally nothing).
+
+Now an **entropy of a random variable** *X*, which can take values *x1*, *x2*, *x3*, ..., *xn* with probabilities *q1*, *q2*, *q3*, ..., *qn* is defined as
+
+*H(x) = sum(qi * Ii) = sum(qi * log2(1/qi))*
+
+**How does entropy differ from information?** Well, they are measured in the same units (bits), the difference is in the interpretation -- under the current context information is basically what we know, while entropy is what we don't know, the uncertainty. So entropy of a certain message (or rather of the probability distribution of possible messages to receive) says how much information will be gained by receiving it -- once we receive the message, the entropy kind of "turns into information", so the amount of information and entropy is actually the same. Perhaps the relationship is similar to that of [energy](energy.md) and work in physics -- both are measured in the same units, energy is the potential for work and can be converted to it.
+
+Entropy is greater if unpredictability ("randomness") is greater -- it is at its maximum if all possible values of the random variable are equally likely. For example entropy of a coin toss is 1 bit, given both outcomes are equally likely (if one outcome was more likely than the other, entropy would go down).
+
+More predictable events have lower entropy -- for example English text has quite low entropy because it is pretty easy to predict missing letters from other letters (there is a lot of redundancy in human language). Thanks to this we can compress the text, e.g. using [Huffman code](huffman_code.md) -- compression reduces size, i.e. removes redundancy/correlation/predictability, and so increases entropy.
+
+**Example**: consider a weather forecast for a specific area, day and hour -- our weather model predicts rain with 55% probability, cloudy with 30% probability and sunny with 15% probability. Once the specific day and hour comes, we will receive a message about the ACTUAL weather that there was in the area. What entropy does such message have? According to the formula above: *H = 0.55 * log2(1/0.55) + 0.3 * log2(1/0.3) + 0.15 * log2(1/0.25) ~= 1.3 bits*. That is the entropy and amount of information such message gives us.
+
+**How is information entropy related to the physics entropy?**
+
 TODO
 
 ## Physics Entropy

lrs_dictionary.md

@@ -5,6 +5,7 @@ WORK IN PROGRESS
 | mainstream                                 | correct/cooler                         |
 | ------------------------------------------ | -------------------------------------- |
 | [cloud](cloud.md) computing                | clown computing                        |
+| [cloudflare](cloudfalre.md)                | cuckflare                              |
 | code of conduct ([COC](coc.md))            | code of coercion                       |
 | [copyright](copyright.md)                  | copywrong, copyrestriction             |
 | digital rights management ([DRM](drm.md))  | digital restrictions management        |

tas.md

@@ -2,7 +2,7 @@
 
 Tool assisted speedrun (TAS, also more generally *tool assisted superplay*) is a category of [game](game.md) [speedruns](speedrun.md) in which help of any tools is allowed, even those that would otherwise be considered [cheating](cheating.md), e.g. scripts, savestates, [aimbots](aimbot.md) or time manipulation, however NOT those that alter the game itself. This makes it possible to create flawless, perfect or near-perfect runs which can serve as a theoretical upper limit for what is achievable by humans -- and of course TAS runs are pretty [fun](fun.md) to watch. The normal, non-TAS runs are called RTA (real time attack). For example the current (2022) RTA world record of Super Mario Bros is 4.58.881 while the TAS record is 4.41.27.
 
-{ Watching a TAS is kind of like watching the [God](god.md) play the game. I personally like to watch Trackmania TASes, some are really unbelievable. Elastomania TASes are also pretty fucked up. Also note that [SAF](saf.md) games have TAS support. ~drummyfish }
+{ Watching a TAS is kind of like watching the [God](god.md) play the game. I personally like to watch [Trackmania](trackmania.md) TASes, some are really unbelievable. Elastomania and [Doom](doom.md) TASes are also pretty fucked up. Also note that [SAF](saf.md) games and [Anarch](anarch.md) have TAS support. ~drummyfish }
 
 There is a website with videos of game TASes: https://tasvideos.org/.