Update

chaos.md

@@ -4,7 +4,7 @@ In [mathematics](math.md) chaos is a phenomenon that makes it extremely difficul
 
 Perhaps the most important point is that a chaotic system is difficult to predict NOT because of [randomness](randomness.md), lack of information about it or even its incomprehensible complexity (many chaotic systems are defined extremely simply), but because of its inherent structure that greatly amplifies any slight nudge to the system and gives any such nudge a great significance. This may be caused by things such as [feedback loops](feedback_loop.md) and [domino effects](domino_effect.md). Generally we describe this behavior as so called **[butterfly effect](butterfly_effect.md)** -- we liken this to the fact that a butterfly flapping its wings somewhere in a forest can trigger a sequence of events that may lead to causing a tornado in a distant city a few days later.
 
-Examples of chaotic systems are the double pendulum, logistic map, weather (which is why it is so difficult to predict it), dice roll, [rule 30](rule_30.md) cellular automaton,  [logistic map](logistic_map.md), gravitational interaction of [N bodies](n_body.md) or [Lorenz differential equations](lorenz_system.md). [Langton's ant](langtons_ant.md) sometimes behaves chaotically. Another example may be e.g. a billiard table with multiple balls: if we hit one of the balls with enough strength, it'll shoot and bounce off of walls and other balls, setting them into motion and so on until all balls come to stop in a specific position. If we hit the ball with exactly the same strength but from an angle differing just by 1 degree, the final position would probably end up being completely different. Despite the system being deterministic (governed by exact and predictable laws of motion, neglecting things like quantum physics) a slight difference in input causes a great different in output.
+Examples of chaotic systems are the double pendulum, weather (which is why it is so difficult to predict it), dice roll, [rule 30](rule_30.md) cellular automaton,  [logistic map](logistic_map.md), gravitational interaction of [N bodies](n_body.md) or [Lorenz differential equations](lorenz_system.md). [Langton's ant](langtons_ant.md) sometimes behaves chaotically. Another example may be e.g. a billiard table with multiple balls: if we hit one of the balls with enough strength, it'll shoot and bounce off of walls and other balls, setting them into motion and so on until all balls come to stop in a specific position. If we hit the ball with exactly the same strength but from an angle differing just by 1 degree, the final position would probably end up being completely different. Despite the system being deterministic (governed by exact and predictable laws of motion, neglecting things like quantum physics) a slight difference in input causes a great different in output.
 
 A simple example of a chaotic equation is also the function *sin(1/x)* for *x* near 0 where it oscillates so quickly that just a tiny shift along the *x* axis drastically changes the result. See how unpredictable results a variant of the function can give:
 

function.md

@@ -82,6 +82,8 @@ Functions commonly used in mathematics range from the trivial ones (such as the
 - **[Dirac delta function](unit_impulse.md)**: Function representing infinitely short impulse with unit energy.
 - TODO
 
+{ Playing around with plotting 2D functions (functions with 2 parameters) is very fun, you can create beautiful pictures with very simple formulas. I once created a tool for this (just some dirty page with JavaScript) and found quite nice functions, for example: `gaussian_curve((x^2) mod (abs(sin(x + y)) + 0.001) + (y^2) mod (abs(sin(x - y)) + 0.001))` plotted from [-3,-3] to [3,3] (plot with amplitude set to range from white to black by given minimum and maximum in the given area). ~drummyfish }
+
 ## Programming Functions
 
 In programming the definition of a function is less strict, even though some languages, namely [functional](functional.md) ones, are built around purely mathematical functions -- for distinction we call these strictly mathematical functions **pure**. In traditional languages functions may or may not be pure, a function here normally means a **subprogram** which can take parameters and return a value, just as a mathematical function, but it can further break some of the rules of mathematical functions -- for example it may have so called **[side effects](side_effect.md)**, i.e. performing additional actions besides just returning a number (such as modifying data in memory which can be read by others, printing something to the screen etc.), or use randomness and internal states, i.e. potentially returning different numbers when invoked (called) multiple times with exactly the same arguments. These functions are called **impure**; in programming a *function* without an adjective is implicitly expected  to be impure. Thanks to allowing side effects these functions don't have to actually return any value, their purpose may be to just invoke some behavior such as writing something to the screen, initializing some hardware etc. The following piece of code demonstrates this in [C](c.md):

lrs_wiki.md

@@ -2,4 +2,6 @@
 
 LRS wiki, also Less Retarded Wiki, is a [public domain](public_domain.md) [encyclopedia](encyclopedia.md) focused on good [technology](tech.md) and related topics such as the relationship between technology and society. The goal of LRS is to work towards creating a truly good technology that helps all living beings as much as possible, so called [less retarded software](lrs.md) (LRS), as well as defining a model of ideal society, so called [less retarded society](less_retarded_society.md). As such the wiki rejects for example [capitalist software](capitalist_software.md), [bloated](bloat.md) software, [intellectual property](intellectual_property.md) laws etc. It embraces [free as in freedom](free_software.md), simple technology, i.e. [Unix philosophy](unix_philosophy.md), [suckless](suckless.md) software, [anarcho pacifism](anpac.md), [racial realism](racial_realism.md), [free speech](free_speech.md), [veganism](veganism.md) etc.
 
-LRS wiki was started by [drummyfish](drummyfish.md) on November 3 2021 as a way of recording and spreading his views and findings about technology, as well as for creating a completely public domain educational resource and account of current society for future generations.
+LRS wiki was started by [drummyfish](drummyfish.md) on November 3 2021 as a way of recording and spreading his views and findings about technology, as well as for creating a completely public domain educational resource and account of current society for future generations.
+
+The wiki is similar to other wikis, for example in its topics and technical aspects it is similar to the earliest (plain HTML) versions of [Wikipedia](wikipedia.md), [wikiwikiweb](wikiwikiweb.md) (by which it was partly inspired) and [permacomputing wiki](permacomputing_wiki.md) (which in turn seems to have been secretly inspired by it). In tone and political incorrectness it is similar to [Encyclopedia Dramatica](dramatica.md).

permacomputing_wiki.md

@@ -0,0 +1,5 @@
+# Permacomputing Wiki
+
+Permacomputing wiki is a computer [minimalist](minimalism.md) wiki whose focus revolves around minimalist, ecology-friendly, [collapse](collapse.md) ready computing; in many ways the wiki is a lot similar to our [LRS wiki](lrs_wiki.md). It was started by [viznut](viznut.md), a famous [demoscene](demoscene.md) programmer, in 2022 and can now be accessed at https://permacomputing.net/.
+
+{ To be honest reading through the wiki makes me conjecture it's actually a LRS wiki ripoff that refuses to admit to it :D Now to make it clear: I don't care if someone copies this wiki or if I get credited or anything like that, on the contrary, I explicitly state in many places this is public domain, that I highly encourage copying, making ripoffs and despise any idea of being able to own an intellectual work. The conjecture here is of purely entertaining nature. If anyone associated with permacomputing wiki is reading this, let me know if the similarities are purely coincidental because yes, we are dealing with similar topic, by similar means, having similar value etc. I also understand no one wants to associate his work with mine, though making a small note for historians somewhere can hardly bring anyone any harm. Why I think it's so similar? Some hints are these: wiki created about half a year after this one, whole design looks pretty similar (similar top-level link, css similar to my website, ...), similar articles (like pseudosimplicity vs [pseudominimalism](pseudominimalism.md), [dependency](dependency.md), [games](game.md), [history](history.md), paper computer, [bloat](bloat.md); sure these are general topic we deal with, but the selection...) with similar content in them (e.g. "A dependency refers to another piece of technology" vs "Dependency of a piece of technology is another piece of technology..."). I don't know, it just at the edge of me being to decide if it's a coincidence or not :P ~drummyfish }

procgen.md

@@ -14,7 +14,7 @@ Using **[fractals](fractal.md)** (e.g. those in a form of [L-system](l_system.md
 
 There are also other techniques such as [wave function](wave_function.md) collapse which is used especially in tile map generation. Here we basically have some constraints set (such as which tiles can be neighbors) and then consider the initial map a [superposition](superposition.md) of all possible maps that satisfy these constraints -- we then set a random tile (chosen from those with lowest [entropy](entropy.md), i.e. fewest possible options) to a random specific value and propagate the consequences of it to other tiles causing a cascading effect of collapsing the whole map into one of the possible solutions.
 
-A good example to think of is generating procedural [textures](texture.md). This is generally done by first generating a basis image or multiple images, e.g. with **[noise](noise.md) functions** such as [Perlin noise](perlin_noise.md) (it gives us a grayscale image that looks a bit like clouds). We then further process this base image(s) and combine the results in various ways, for example we may use different transformations, [modulations](modulation.md), blending, adding color using [color ramps](color_ramp.md) etc. The whole texture is therefore described by a [graph](graph.md) in which nodes represent the operations we apply; this can literally be done visually in software like [Blender](blender.md) (see its [shader](shader.md) editor). The nice thing is that we can now for example generalize the texture to 3 dimensions, i.e. not only have a flat image, but have a whole volume of a texture that can extremely easily be mapped to 3D objects simply by intersecting it with their surfaces which will yield a completely smooth texturing without any seams; this is quite often used along with [raytracing](raytracing.md) -- we can texture an object by simply taking the coordinates of the ray hit as the 3D texture coordinates, it's that simple. Or we can animate a 2D texture by doing a moving cross section of 3D texture. We can also write the algorithm so that the generated texture has no seams if repeated side-by-side (by using modular "wrap-around" coordinates). We can also generate the texture at any arbitrary resolution as we have a continuous mathematical description of it; we may perform an infinite zoom into it if we want. As if that's not enough, we can also generate almost infinitely many slightly different versions of this texture by simply changing the [seed](seed.md) of [pseudorandom](pseudorandom.md) generator we use.
+A good example to think of is generating procedural [textures](texture.md) -- similar techniques may also be used to create procedural terrain [heightmaps](heightmap.md) etc. This is generally done by first generating a basis image or multiple images, e.g. with **[noise](noise.md) functions** such as [Perlin noise](perlin_noise.md) (it gives us a grayscale image that looks a bit like clouds). We then further process this base image(s) and combine the results in various ways, for example we may use different transformations, [modulations](modulation.md), blending, adding color using [color ramps](color_ramp.md) etc. The whole texture is therefore described by a [graph](graph.md) in which nodes represent the operations we apply; this can literally be done visually in software like [Blender](blender.md) (see its [shader](shader.md) editor). The nice thing is that we can now for example generalize the texture to 3 dimensions, i.e. not only have a flat image, but have a whole volume of a texture that can extremely easily be mapped to 3D objects simply by intersecting it with their surfaces which will yield a completely smooth texturing without any seams; this is quite often used along with [raytracing](raytracing.md) -- we can texture an object by simply taking the coordinates of the ray hit as the 3D texture coordinates, it's that simple. Or we can animate a 2D texture by doing a moving cross section of 3D texture. We can also write the algorithm so that the generated texture has no seams if repeated side-by-side (by using modular "wrap-around" coordinates). We can also generate the texture at any arbitrary resolution as we have a continuous mathematical description of it; we may perform an infinite zoom into it if we want. As if that's not enough, we can also generate almost infinitely many slightly different versions of this texture by simply changing the [seed](seed.md) of [pseudorandom](pseudorandom.md) generator we use.
 
 We use procedural generation mainly in two ways:
 
@@ -23,6 +23,25 @@ We use procedural generation mainly in two ways:
 
 Indeed we may also do something "in between", e.g. generate procedural assets into temporary files or RAM [caches](cache.md) at run time and depending on the situation, for example when purely realtime generation of such assets would be too slow.
 
+## Notable Techniques
+
+The following are some techniques often used in procedural generation:
+
+- **[noise](noise.md)**: Noise is often used as a basis for generation or for modulation, it can be seen as kind of "RNG taken to the next level" -- noise is greatly random but also usually has some structure, for example it may resemble smoke or water ripples. There are great many types of noise and algorithms for its generation; the simplest [white noise](white_noise.md) is actually not very useful, more common are various forms of fractal noise, often used noises are [Perlin noise](perlin_noise.md), [simplex noise](simplex_noise.md) etc., other ones are [Voronoi](voronoi.md) diagrams, midpoint displacement, spot noise, cosine noise, fault formation etcetc.
+- **[random number generators](rng.md)**: To make random decisions we use random number generators -- here we actually don't have to have the best generators, we aren't dealing with "security" or anything critical, however the generator should at least have a great period so that it's not limited to just generating few different results, and its useful to be able to choose [probability distribution](probability_distribution.md).
+- **[modulation](modulation.md)**: Using previously generated procedural data, for example noise, to somehow affect another data -- for example imagine we already have some basic procedural texture but want to make it more interesting by randomly displacing its individual pixels to warp it a little bit. If we use a simple random number generator for each pixel, the result will just look too chaotic, so it's better if we e.g. use two additional Perlin noise textures, which together say for each pixel by what distance and angle we'll displace the pixel. As Perlin noise is more continuous, gradual noise, then also the distortion will be kind of continuous and nice.
+- **simulations resembling natural/biological phenomena**: E.g. [cellular automata](cellular_automaton.md), [particle systems](particle_system.md), ...
+- **[fractals](fractal.md)**: Fractals can resemble nature, they create "content" on all scales and are very simple to define. Popular types of fractals are e.g. [L-systems](l_system.md) that draw fractals with [turtle graphics](turtle_graphics.md).
+- **coloring**: To get colors from simple numeric values we may use e.g. color mapping of the values to some [palette](palette.md) or using three different arrays as [RGB](rgb.md) channels. We may also use [flood fill](flood_fill.md) and other things of course.
+- **wave function collapse**: Analogy to quantum mechanics, often used for generating tile maps.
+- **combining intermediate results**: For example when creating procedural textures we may actually create two separate textures and then somehow [blend](blending.md) them together to get a more interesting result.
+- **wrap-around coordinates**: Wrap around (modular) coordinates help us make tiling data.
+- **mathematical [functions](function.md)**: Nice structures can be generated just by combining basic mathematical functions such as [sine](sin.md), [cosine](cos.md), [square root](sqrt.md), minimum/maximum, [logarithm](log.md) etc. We take these functions and make an expression that transforms input coordinates (i.e. for example *x*, *y* and *time* for an animated picture) to the final generated value. The functions may be composed (put on input of other functions), added, multiplied etc.
+- **higher [dimensionality](dimension.md)**: Equations used for procedural generation are often generalized to higher dimensions so that we can for example create smooth animation by taking the extra dimension as time.
+- **[filters](filter.md)**: We may utilize traditional graphic filters such as Gaussian blur, [median](median.md) blur, general [convolution](convolution.md), color adjustments etc.
+- **[stochastic](stochastic.md) models**: Stochastic mathematical models describe the generated result in terms of probabilities, which is convenient for us as we can take the model and just use random number generators to make decisions with given probabilities to obtain a specific result. For example [Markov chains](markov_chain.md) can be used to easily generate random procedural text by knowing probabilities with which any word is followed by another word, this may also be used to generate linear game levels etc. Similarly we may utilize various non-[deterministic](determinism.md) finite state automata, [decision trees](decision_tree.md) etc.
+- ...
+
 ## Examples
 
 Here are some cool [ASCII renderings](ascii_art.md) of procedurally generated pictures:

xxiivv.md

@@ -14,4 +14,8 @@ There are also nice things though, a few of them being:
   - [uxn](uxn.md): Simple (~100 [LOC](loc.md) of [C](c.md)) [virtual machine](virtual_machine.md), similar to a "[fantasy console](fantasy_console.md)" but intended more for [portability](portability.md). This also comes with an assembly language called [tal](tal.md).
   - [lietal](lietal.md): Simple [artificial language](conlang.md).
 - The wiki writes on pretty [interesting](interesting.md) topics, many of which overlap with [our](lrs.md) topics of interest. For example [pen and paper computing](pen_and_paper.md) that includes [games](game.md).
-- Some of the presented opinions and wisdoms are [based](based.md), e.g. "for writing fast programs use slow computers" etc.
+- Some of the presented opinions and wisdoms are [based](based.md), e.g. "for writing fast programs use slow computers" etc.
+
+## See Also
+
+- [permacomputing wiki](permacomputing_wiki.md)