Update
This commit is contained in:
parent
5c43f56dc3
commit
1c2717e515
8 changed files with 48 additions and 29 deletions
|
|
@ -1,6 +1,6 @@
|
|||
# 3D Rendering
|
||||
|
||||
In [computer graphics](graphics.md) 3D rendering is concerned with computing images that represent a projected view of 3D objects through a virtual camera.
|
||||
In [computer graphics](graphics.md) 3D rendering is the process of computing images which represent a projected view of 3D objects through a virtual camera.
|
||||
|
||||
There are many methods and [algorithms](algorithm.md) for doing so differing in many aspects such as computation complexity, implementation complexity, realism of the result, representation of the 3D data, limitations of viewing and so on. If you are just interested in the [realtime](realtime.md) 3D rendering used in [gaymes](game.md) nowadays, you are probably interested in [GPU](gpu.md)-accelerated 3D [rasterization](rasterization.md) with [APIs](api.md) such as [OpenGL](opengl.md) and [Vulkan](vulkan.md).
|
||||
|
||||
|
|
@ -8,7 +8,7 @@ There are many methods and [algorithms](algorithm.md) for doing so differing in
|
|||
|
||||
## Methods
|
||||
|
||||
As most existing 3D "frameworks" are harmful, a [LRS](lrs.md) programmer is likely to write his own 3D rendering system that suits his program best, therefore we should list some common methods of achieving 3D. Besides that, it's just pretty interesting to see what there is in the store.
|
||||
As most existing 3D "[frameworks](framework.md)" are [harmful](harmful.md), a [LRS](lrs.md) programmer is likely to write his own 3D rendering system that suits his program best, therefore we should list some common methods of achieving 3D. Besides that, it's just pretty interesting to see what there is in the store.
|
||||
|
||||
**Rendering spectrum**: The book *Real-Time Rendering* mentions that methods for 3D rendering can be seen as lying on a spectrum, one extreme of which is *appearance reproduction* and the other *physics simulation*. Methods closer to trying to imitate the appearance try to simply focus on imitating the look of an object on the monitor that the actual 3D object would have in real life, without being concerned with *how* that look arises in real life -- these may e.g. use image data such as photographs; these methods may rely on lightfields, photo [textures](texture.md) etc. The physics simulation methods try to replicate the behavior of light in real life -- their main goal is to solve the **[rendering equation](rendering_equation.md)**, usually only [approximately](approximation.md) -- and so, through internally imitating the same processes, come to similar visual results that arise in real world: these methods rely on creating 3D geometry (e.g. that made of triangles or voxels), computing light reflections and [global illumination](global_illumination.md). Most methods lie somewhere in between these two extremes: for example [billboards](billboard.md) and [particle systems](particle_system.md) may use a texture to represent an object while at the same time using 3D quads (very simple 3D models) to correctly deform the textures by perspective and solve their visibility. The classic polygonal 3D models are also usually somewhere in between: the 3D geometry and [shading](shading.md) are trying to simulate the physics, but e.g. a photo texture mapped on such 3D model is the opposite appearance-based approach ([PBR](pbr.md) further tries to shift the use of textures more towards the *physics simulation* end).
|
||||
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
|
||||
Abstraction is an important concept in [programming](programming.md), [mathematics](math.md) and other fields of science, philosophy and art, which in simple words can be described as "viewing an issue from a distance", thinking in higher-level concepts, i.e. paying less attention to fine detail so that one can see the bigger picture. In programming for example we distinguish [programming languages](programming_language.md) of high and low level of abstraction, depending on how close they are "to the [hardware](hardware.md)" (e.g. [assembly](assembly.md) being low level, [JavaScript](js.md) being high level); in [art](art.md) high abstraction means portraying and capturing things such as ideas, feelings and emotions with shapes that may seem "distant", not resembling anything concrete or familiar. We usually talk about different **levels of abstraction**, depending on the "distance" we take in vieweing the issue at hand -- this concept may very well be demonstrated on [sciences](science.md): particle [physics](physics.md) researches the world at the lowest level of abstraction, in extreme close-up, for example by examining individual atoms that make up our brains, while [biology](biology.md) resides at a higher level of abstraction, viewing the brain at the level of individual cells, and finally [psychology](psychology.md) shows a very high level of abstraction because it looks at the brain from great distance and just studies its behavior.
|
||||
|
||||
In mainstream [programming](programming.md) education it is generally taught to "abstract as much as possible" because that's aligned with the [capitalist](capitalism.md) way of technology -- high abstraction is easy to handle for incompetent programming monkeys, it helps preventing them from making damage by employing billions of safety mechanisms, it also perpetuates the cult of never stopping layering of the abstraction sandwich, creating [bloat](bloat.md), bullshit jobs, it makes computers slower, constantly outdated and so drives software consumerism. **This is extremely wrong.** [LRS](lrs.md) advocates to employ only as little abstraction as needed, so as to support [minimalism](minimalism.md), i.e. **too much abstraction is bad.** For example a widely used general purpose programming language should basically only have as much abstraction as to allow [portability](portability.md), it should definitely NOT succumb high abstraction such as [object obsessed programming](oop.md).
|
||||
In mainstream [programming](programming.md) education it is generally taught to "abstract as much as possible" because that's aligned with the [capitalist](capitalism.md) way of technology -- high abstraction is easy to handle for incompetent programming monkeys, it helps preventing them from making damage by employing billions of safety mechanisms, it also perpetuates the cult of never stopping layering of the abstraction sandwich, creating [bloat](bloat.md), [hype](hype.md), bullshit jobs, it makes computers slower, constantly outdated and so drives software [consumerism](consumerism.md). As with everything in capitalism, new abstractions are products hyped on grounds of immediate benefit: creating more comfort, being something new and "[modern](modern.md)", increasing "[productivity](productivity_cult.md)", lowering "barriers of entry" so that ANYONE CAN NOW BE A PROGRAMMER without even knowing anything about computers (try to imagine this e.g. in the field of medicine) etc. -- of course, long term negative effects are completely ignored. **This is extremely wrong.** It is basically why technology has been on such a huge downfall in the latest decades. Opposing this, [LRS](lrs.md) advocates to employ only as little abstraction as needed, so as to support [minimalism](minimalism.md). **Too much abstraction is bad.** For example a widely used general purpose programming language should basically only have as much abstraction as to allow [portability](portability.md), it should definitely NOT succumb high abstraction such as [object obsessed programming](oop.md).
|
||||
|
||||
In a more detailed view abstraction is not one-dimensional, we may abstract in different directions ("look at the issue from different angles"); for example [functional](functional.md), [logic](logic_paradigm.md) and [object](object.md) paradigms are different ways of abstracting from the low level, each one in different way. So the matter of abstracting is further complicated by trying to **choose the right abstraction** -- one kind of abstraction may work well for certain kinds of problems (i.e. solving these problems will become simple when applying this abstraction) but badly for other kinds of problems.
|
||||
|
||||
|
|
|
|||
16
algorithm.md
16
algorithm.md
|
|
@ -1,18 +1,18 @@
|
|||
# Algorithm
|
||||
|
||||
Algorithm (from the name of Persian mathematician Muhammad ibn Musa al-Khwarizmi) is an exact step-by-step description of how to solve some type of a problem. Algorithms are basically what [programming](programming.md) is all about: we tell [computers](computer.md), in very exact ways (with [programming languages](programming_language.md)), how to solve problems -- we write algorithms. But algorithms don't have to be just computer programs, they are simply instruction for solving problems.
|
||||
Algorithm (from the name of Persian mathematician Muhammad ibn Musa al-Khwarizmi) is an exact step-by-step description of how to solve some type of a problem. Algorithms are basically what [programming](programming.md) is all about: we tell [computers](computer.md), in very exact ways (with [programming languages](programming_language.md)), how to solve problems -- we write algorithms. But algorithms don't have to be just computer programs, they are simply exact instruction for solving problems.
|
||||
|
||||
Cooking recipes are commonly given as an example of a non-computer algorithm, though they rarely contain branching ("if then...") and loops ("while a condition holds do ..."), the key features of algorithms. The so called wall-follower is a simple algorithm to get out of any [maze](maze.md): you just pick either a left-hand or right-hand wall and then keep following it. You may write a crazy algorithm basically for any kind of problem, e.g. for how to clean a room or how to get a [girl](woman.md) to bed, but it has to be **precise** so that anyone can execute the algorithm just by blindly following the steps; if there is any ambiguity, it is not considered an algorithm; a vague, imprecise "hint" on how to find a solution (e.g. "to get to the airport head somewhere in this direction.") we rather call a [heuristic](heuristic.md). Heuristics are useful too and they may be utilized by an algorithm, e.g. to find a precise solution faster, but from programmer's point of view algorithms, the PRECISE ways of finding solutions, are the basic of everything.
|
||||
Cooking recipes are commonly given as an example of a non-computer algorithm, though they rarely contain branching ("if condition holds then do...") and loops ("while a condition holds do ..."), the key features of algorithms. The so called wall-follower is a simple algorithm to get out of any [maze](maze.md) which doesn't have any disconnected walls: you just pick either a left-hand or right-hand wall and then keep following it. You may write a crazy algorithm basically for any kind of problem, e.g. for how to clean a room or how to get a [girl](woman.md) to bed, but it has to be **precise** so that anyone can execute the algorithm just by blindly following the steps; if there is any ambiguity, it is not considered an algorithm; a vague, imprecise "hint" on how to find a solution (e.g. "the airport is somewhere in this general direction.") we rather call a [heuristic](heuristic.md). Heuristics are useful too and they may be utilized by an algorithm, e.g. to find a precise solution faster, but from programmer's point of view algorithms, the PRECISE ways of finding solutions, are the basics of everything.
|
||||
|
||||
Interesting fact: contrary to intuition there are problems that are mathematically proven to be unsolvable by any algorithm, see [undecidability](undecidability.md), but for most practically encountered problems we can write an algorithm (though for some problems even our best algorithms can be unusably [slow](time_complexity.md)).
|
||||
|
||||
Algorithms are mostly (possibly [not always](declarative.md), depending on exact definition of the term) written as a **series of steps** (or instructions); these steps may be specific actions (such as adding two numbers or drawing a pixel to the screen) or **conditional jumps** to other steps ("if condition X holds then jump to step N, otherwise continue"). At the lowest level ([machine code](machine_code.md), [assembly](assembly.md)) computers can do just that: execute instructions (expressed as [1s and 0s](binary.md)) and perform conditional jumps. These jumps can be used to create **[branches](branch.md)** (in programming known as *if-then-else*) and **[loops](loop.md)**. Branches and loops are together known as [control structures](control_structure.md) -- they don't express a direct action but control which steps in the algorithm will follow. All in all, **any algorithm can be written with only these three constructs**:
|
||||
Algorithms are mostly (possibly [not always](declarative.md), depending on exact definition of the term) written as a **series of steps** (or "instructions"); these steps may be specific actions (such as adding two numbers or drawing a pixel to the screen) or **conditional jumps** to other steps ("if condition X holds then jump to step N, otherwise continue"). At the lowest level ([machine code](machine_code.md), [assembly](assembly.md)) computers cannot do anything more complex than that: execute simple instructions (expressed as [1s and 0s](binary.md)) and perform conditional jumps -- in this computers are quite dumb (their strength comes from being able to execute many instruction with extreme speed). These jumps can be used to create **[branches](branch.md)** (in programming known as *if-then-else*) and **[loops](loop.md)**. Branches and loops are together known as [control structures](control_structure.md) -- they don't express a direct action but control which steps in the algorithm will follow. All in all, **any algorithm can be built just using these three basic constructs**:
|
||||
|
||||
- **sequence**: A series of steps, one after another. E.g. "write prompt, read number from input, store than number to memory".
|
||||
- **selection** (branches, *if-then-else*): Two branches (sequences of steps) preceded by a condition; the first branch is executed only if the condition holds, the second ("else") branch is executed only if the condition doesn't hold (e.g. "If user password is correct, log the user in, otherwise print out an error.").
|
||||
- **iteration** (loops, repetition): Sequence of steps that's repeated as long as certain condition holds (e.g. "As long as end of file is not reached, read and print out next character from the file.").
|
||||
- **sequence**: A series of steps, one after another. E.g. "write prompt, read number from input, multiply it by two, store it to memory".
|
||||
- **selection** (branches, *if-then-else*): Two branches (blocks of instructions) preceded by a condition; the first branch is executed only if the condition holds, the second ("else") branch is executed only if the condition doesn't hold (e.g. "If user password is correct, log the user in, otherwise print out an error."). The second branch is optional (it may remain empty).
|
||||
- **iteration** (loops, repetition): Sequence of steps that's repeated as long as certain condition holds (e.g. "As long as end of file is not reached, read and print out the next character from the file.").
|
||||
|
||||
Note: in a wider sense algorithms may be expressed in other ways than sequences of steps (non-[imperative](imperative.md) ways, see [declarative languages](declarative.md)), even mathematical equations are often called algorithms because they *imply* the steps towards solving a problem. But we'll stick to the common meaning of algorithm given above.
|
||||
Note: in a wider sense algorithms may be expressed in other (mathematically equivalent) ways than sequences of steps (non-[imperative](imperative.md) ways, see [declarative languages](declarative.md)), even mathematical equations are often called algorithms because they *imply* the steps towards solving a problem. But we'll stick to the common narrow meaning of algorithm given above.
|
||||
|
||||
Additional constructs can be introduced to make programming more comfortable, e.g. [subroutines/functions](function.md) (kind of small subprograms that the main program uses for solving the problem), [macros](macro.md) (shorthand commands that represent multiple commands) or [switch](switch.md) statements (selection but with more than two branches). Loops are also commonly divided into several types such as: counted loops, loops with condition and the beginning, loops with condition at the end and infinite loops (`for`, `while`, `do while` and `while (1)` in [C](c.md), respectively) -- in theory there can only be one generic type of loop but for convenience programming languages normally offer different "templates" for commonly used loops. Similarly to mathematical equations, algorithms make use of [variables](variable.md), i.e. values which can change and which have a specific name (such as *x* or *myVariable*).
|
||||
|
||||
|
|
@ -20,7 +20,7 @@ Practical programming is based on expressing algorithms via [text](text.md), but
|
|||
|
||||
## Example
|
||||
|
||||
Let's write a simple algorithm that counts the number of divisors of given number *x* and checks if the number is [prime](prime.md) along the way. (Note that we'll do it in a naive, educational way -- it can be done better). Let's start by writing the steps in plain [English](english.md):
|
||||
Let's write a simple algorithm that counts the number of divisors of given number *x* and checks if the number is [prime](prime.md) along the way. (Note that we'll do it in a [naive](naive.md), educational way -- it can be done better). Let's start by writing the steps in plain [English](english.md) (sometimes called [pseudocode](pseudocode.md)):
|
||||
|
||||
1. Read the number *x* from the input.
|
||||
2. Set the *divisor counter* to 0.
|
||||
|
|
|
|||
10
copyleft.md
10
copyleft.md
|
|
@ -1,16 +1,16 @@
|
|||
# Copyleft
|
||||
|
||||
Copyleft (also share-alike) is a concept of sharing something on the condition that others will share it under the same terms; this is practically always used by a subset of [free (as in freedom) software](free_software.md) and [culture](free_culture.md) to legally ensure this software/art and its modifications will always remain free. This kind of [hacks](hacking.md) [copyright](copyright.md) to de-facto remove copyright by its own power.
|
||||
Copyleft (also share-alike) is a concept of allowing sharing and modifications of intellectual works (such as pictures, music or computer programs) on the legal condition that others will share it under the same terms (i.e. that they will also allow the work's further free sharing and modification etc.); it was created by the critics of [copyright](copyright.md) as a "more sane" take on sharing. Copyleft is widely utilized by some proponents of [free (as in freedom) software](free_software.md) and [culture](free_culture.md) to legally ensure this software/art and its modifications will always remain free, however other camps of freedom proponents argue that copyleft is still to restrictive and share their works under [even more relaxed](premissive.md) legal conditions. Copyleft kind of [hacks](hacking.md) [copyright](copyright.md) to de-facto remove copyright (the monopoly it creates) by its own power.
|
||||
|
||||
Copyleft has been by its mechanisms likened to a virus because once it is applied to certain software, it "infects" it and will force its conditions on any [descendants](fork.md) of that software, i.e. it will spread itself (in this case the word virus does not bear a negative connotation, at least to some, they see it as a good virus).
|
||||
Copyleft has been by its mechanisms likened to a virus because once it is applied to certain software, it "infects" it and will force its conditions on any [descendants](fork.md) of that software, i.e. it will spread itself (in this case the word virus does not bear a negative connotation, at least to some, they see it as a "good virus").
|
||||
|
||||
For free/open-source software the alternative to copyleft is so called **permissive** licensing which (same as with copyleft) grants all the necessary freedom rights, but does NOT require modified versions to grant these rights as well. This allows free software being forked and developed into [proprietary](proprietary.md) software and is what copyleft proponents criticize. However, both copyleft and permissive licensing are free as in freedom.
|
||||
For free/open-source software the alternative to copyleft is so called **[permissive](permissive.md)** licensing which (same as with copyleft) grants all the necessary freedom rights, but, unlike copyleft, does NOT require further modified versions to grant these rights as well. This allows free software being forked and developed into [proprietary](proprietary.md) software and is what copyleft proponents criticize. However, both copyleft and permissive licensing are free as in freedom.
|
||||
|
||||
In the [FOSS](foss.md) world there is a huge battle between the copyleft camp and permissive camp ([LRS](lrs.md) advocates permissive licenses with a preference for 100% [public domain](public_domain.md)).
|
||||
In the [FOSS](foss.md) world there is a huge battle between the copyleft camp and permissive camp (our [LRS](lrs.md) advocates permissive licenses with a preference for 100% [public domain](public_domain.md)). These debates go beyond mere technology and law for the basic disagreement lies in whether freedom should be forced and if forced freedom really is freedom, thereby getting into questions of politics, ideologies, philosophy, morality and [ethics](ethics.md).
|
||||
|
||||
## Issues With Copyleft
|
||||
|
||||
In the great debate of copyleft vs permissive free licenses we, as technological anarchists, stand on the permissive side. Here are some reasons for why we reject copyleft:
|
||||
In the great debate of copyleft vs permissive free licenses we, as technological [anarchists](anarchism.md) who oppose any "intellectual property" laws and their enforcement, stand on the permissive side. Here are some reasons for why we reject copyleft:
|
||||
|
||||
- It **burdens the reuser of the work by requiring him to do something extra** -- while a public domain and many permissive licensed works can simply be taken and used without taking any extra action, just as it should ideally be, a work under copyleft requires its user to take an action, for example copying the license file (and then forever making sure it doesn't get lost), giving credit etc. While one may think this is not such a big deal, it's a form of friction that can get in the way of creativity, especially when combining many works under possibly different copyleft licenses which suddenly becomes quite cumbersome to handle.
|
||||
- By adopting copyleft one is **embracing and supporting the copyright laws and perpetuating the [capitalist](capitalism.md) ways** ("marrying the lawyers") because copyleft relies on and uses copyright laws to function; to enforce copyleft (prevent "disallowed" use) one has to make a legal action (while with permissive license we simply basically give up the rights to make a legal action). Copyleft chooses to play along with the capitalist bullshit [intellectual property](intellectual_property.md) game and threatens to [fight](fight_culture.md) and use force and bullying in order to enforce *correct* usage of information.
|
||||
|
|
|
|||
2
doom.md
2
doom.md
|
|
@ -1,6 +1,6 @@
|
|||
# Doom
|
||||
|
||||
Doom is a legendary video [game](game.md) released in 1993, perhaps the most famous video game of all time, the game that popularized the [first person shooter](first_person_shooter.md) genre and shocked by its at the time extremely advanced [3Dish](pseudo_3D.md) graphics. It was made by [Id Software](id_software.md), most notably by [John Carmack](john_carmack.md) (graphics + engine programmer) and [John Romero](john_romero.md) (tool programmer + level designer). Doom is sadly [proprietary](proprietary.md), it was originally distributed as [shareware](shareware.md) (a free "demo" was available for playing and sharing with the option to buy a full version). However the game engine was later (1999) released as [free (as in freedom) software](free_software.md) under [GPL](gpl.md) which gave rise to many source [ports](port.md). The assets remain non-free but a completely free alternative is offered by the [Freedoom](freedoom.md) project that has created [free as in freedom](free_culture.md) asset replacements for the game. [Anarch](anarch.md) is an official [LRS](lrs.md) game inspired by Doom, completely in the [public domain](public_domain.md).
|
||||
Doom is a legendary video [game](game.md) released in 1993, perhaps the most famous video game of all time, the game that popularized the [first person shooter](first_person_shooter.md) genre and shocked by its at the time extremely advanced [3D](pseudo_3D.md) graphics (yes, it was actually 3D). It was made by [Id Software](id_software.md), most notably by [John Carmack](john_carmack.md) (graphics + engine programmer) and [John Romero](john_romero.md) (tool programmer + level designer). Doom is sadly [proprietary](proprietary.md), it was originally distributed as [shareware](shareware.md) (a free "demo" was available for playing and sharing with the option to buy a full version). However the game engine was later (1999) released as [free (as in freedom) software](free_software.md) under [GPL](gpl.md) which gave rise to many source [ports](port.md). The assets remain non-free but a completely free alternative is offered by the [Freedoom](freedoom.md) project that has created [free as in freedom](free_culture.md) asset replacements for the game. [Anarch](anarch.md) is an official [LRS](lrs.md) game inspired by Doom, completely in the [public domain](public_domain.md).
|
||||
|
||||
{ Great books about Doom I can recommend: *Masters of Doom* (about the development) and *Game Engine Black Book: Doom* (details about the engine internals). ~drummyfish }
|
||||
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ These are some **nice/interesting/benchmark articles** to look up in encyclopedi
|
|||
|
||||
## Notable/Nice Encyclopedias
|
||||
|
||||
Here is a list of notable encyclopedias, focused on general knowledge English language ones. The most notable ones are in bold.
|
||||
Here is a list of notable encyclopedias, focused on general knowledge English language ones. The most notable ones are in bold. Also check out existing encyclopedias in other languages that you speak, we can't list those here.
|
||||
|
||||
{ See also https://wikiindex.org/. ~drummyfish }
|
||||
|
||||
|
|
|
|||
21
recursion.md
21
recursion.md
|
|
@ -18,7 +18,26 @@ unsigned int factorial(unsigned int x)
|
|||
}
|
||||
```
|
||||
|
||||
See that as long as x > 1, recursive calls are being made; with each the x is decremented so that inevitably x will at one point come to equal 1. Then the *else* branch of the condition will be taken -- the terminating condition has been met -- and in this branch no further recursive call is made, i.e. the recursion is stopped here and the code starts to descend from the recursion.
|
||||
See that as long as x > 1, recursive calls are being made; with each the x is decremented so that inevitably x will at one point come to equal 1. Then the *else* branch of the condition will be taken -- the terminating condition has been met -- and in this branch no further recursive call is made, i.e. the recursion is stopped here and the code starts to descend from the recursion. The following diagram show graphically computation of `factorial(4)`:
|
||||
|
||||
```
|
||||
factorial(4) = 4 * 6 = 24
|
||||
| ^
|
||||
| | return
|
||||
| '------------.
|
||||
| call |
|
||||
'-----> factorial(3) = 3 * 2 = 6
|
||||
| ^
|
||||
| | return
|
||||
| '------------.
|
||||
| call |
|
||||
'-----> factorial(2) = 2 * 1 = 2
|
||||
| ^
|
||||
| | return
|
||||
| '-----.
|
||||
| call |
|
||||
'------> factorial(1) = 1 <-- end condition met
|
||||
```
|
||||
|
||||
Note that even in computing we can use an infinite recursion sometimes. For example in [Hashell](haskell.md) it is possible to define infinite [data structures](data_structure.md) with a recursive definition; however this kind of recursion is intentionally allowed, it is treated as a mathematical definition and with correct use it won't crash the program.
|
||||
|
||||
|
|
|
|||
|
|
@ -22,13 +22,13 @@ In other words given *N* bits, the positive values representable by two's comple
|
|||
|
||||
The following is a comparison of the different representations, notice the shining superiority of two's complement:
|
||||
|
||||
| value | unsigned | two's com. | sign-mag. | one's com. |
|
||||
|-------|----------|------------|-----------|------------|
|
||||
| 000 | 0 | 0 | 0 | 0 |
|
||||
| 001 | 1 | 1 | 1 | 1 |
|
||||
| 010 | 2 | 2 | 2 | 2 |
|
||||
| 011 | 3 | 3 | 3 | 3 |
|
||||
| 100 | 4 | -4 | -0 | -3 |
|
||||
| 101 | 5 | -3 | -1 | -2 |
|
||||
| 110 | 6 | -2 | -2 | -1 |
|
||||
| 111 | 7 | -1 | -3 | -0 |
|
||||
| value | unsigned | two's com. | sign-mag. | one's com. | biased |
|
||||
| ----- | -------- | ---------- | --------- | ---------- | ------ |
|
||||
| 000 | 0 | 0 | 0 | 0 | -4 |
|
||||
| 001 | 1 | 1 | 1 | 1 | -3 |
|
||||
| 010 | 2 | 2 | 2 | 2 | -2 |
|
||||
| 011 | 3 | 3 | 3 | 3 | -1 |
|
||||
| 100 | 4 | -4 | -0 | -3 | 0 |
|
||||
| 101 | 5 | -3 | -1 | -2 | 1 |
|
||||
| 110 | 6 | -2 | -2 | -1 | 2 |
|
||||
| 111 | 7 | -1 | -3 | -0 | 3 |
|
||||
|
|
|
|||
Loading…
Reference in a new issue