OpenLLM-France/wikimedia huggingface dataset:
# Kadas Opening
### 1...d5

Black takes the center and opens the diagonal for the light-squared bishop, preventing White's kingside rook from coming out with 2. Rh3??, to which Black will respond with Bxh3. White may try to rectify this with 3. h5?!, but this allows Black to take the full center with 3... e5! not allowing the rook to come to h4 either.

## Responses

White may respond to the move d5 with:
* 2. h5, allowing Black to take the full center with 2...e5,
* 2. d4, which is more principled, and White will always play d4 in this opening so why not?
* or 2. Nf3, controlling the center with a knight and either going into a King's Indian-like defense, playing classically, or just transposing into the d4 line.
| 1. h4 d5 | |
| | 2 | 3 | 4 | 5 | 6 | |
| Croon's Gambit Accepted: Risky Variation | h5?! e5 | h6?! gxh6?! | d4 e4?! | Bf4 Nc6 | e3 Bf5?! | ± |
| Croon's Gambit Accepted: Knight's Acception | ... ... | ... Nxh6 | d4 e4?! | Bxh6 gxh6 | e3 Nc6?! | ± |
| Croon's Gambit Accepted: Knight's Acception | ... ... | ... ... | ... ... | ... ... | ... Bg7 | = |
| Croon's Gambit Declined: Thorn Defense | ... ... | ... g6 | e5 d4 | e4 Bf4?! | Bd6 Bxd6 | = |
| Kadas Opening: King's Indian Variation | Nf3 Nc6 | d4 Nf6 | g3 Bg4 | Bg2 e6 | O-O Bd6 | = |
| Kadas Opening: Center Variation | d4 Nc6?! | h5?! h6 | Nf3 Nf6 | Nc3 Bg4 | Bf4 e6 | = |
| Transposition to Center Variation | Nf3 Nc6 | d4 Nf6 | h5?! h6 | - - | - - | = |
# Computer Science Design Patterns/Interpreter

Given a language, define a representation for its grammar along with an interpreter that uses the representation to interpret sentences in the language.

## Examples

The following Reverse Polish notation example illustrates the interpreter pattern. The grammar:
expression ::= plus | minus | variable | number plus ::= expression expression '+' minus ::= expression expression '-' variable ::= 'a' | 'b' | 'c' | ... | 'z' digit ::= '0' | '1' | ... '9' number ::= digit | digit number
defines a language which contains reverse Polish expressions like:
a b + a b c + - a b + c a - -
Following the interpreter pattern there is a class for each grammar rule.

## Cost

This pattern is not expensive. It dramatically reduces the business code so there is only few code to handle.

### Creation

If the code already exists, this pattern is a little expensive.

### Maintenance

This pattern is very easy to maintain. There is no additional cost due to the pattern.

### Removal

This pattern is easy to remove with refactoring operations from your IDE.

## Advises

* Use the Interpreter term to indicate the use of the pattern to the other developers.

## Implementations

The following Backus–Naur form example illustrates the interpreter pattern. The grammar
defines a language that contains Reverse Polish Notation expressions like:
This structural code demonstrates the Interpreter patterns, which using a defined grammar, provides the interpreter that processes parsed statements.
Another example:
While the interpreter pattern does not address parsing, a parser is provided for completeness.
Finally evaluating the expression "w x z - +" with w = 5, x = 10, and z = 42.
Another example:
While the interpreter pattern does not address parsing a parser is provided for completeness.
Finally evaluating the expression "w x z - +" with w = 5, x = 10, and z = 42.
As JavaScript is dynamically typed, we do not implement an interface.
Example 1:
Example 2: Based on the example above with another realization of the client.
Example 3: In a file we have the classes and the interface, defining the logic of the program (and applying the Interpreter pattern). Now the expr.php file:
And the evaluate.php:
And you can run on a terminal by typing php5 -f evaluator.php (or putting it on a web application).
# Computer Science Design Patterns/Flyweight

It is a mechanism by which you can avoid creating a large number of object instances to represent the entire system. To decide if some part of a program is a candidate for using Flyweights, consider whether it is possible to remove some data from the class and make it extrinsic.

## Examples

A classic example usage of the flyweight pattern is the data structures for graphical representation of characters in a word processor. It might be desirable to have, for each character in a document, a glyph object containing its font outline, font metrics, and other formatting data, but this would amount to hundreds or thousands of bytes for each character. Instead, for every character there might be a reference to a flyweight glyph object shared by every instance of the same character in the document; only the position of each character (in the document and/or the page) would need to be stored internally. Another example is string interning.
In video games, it is usual that you have to display the same sprite (i.e. an image of an item of the game) several times. It would highly use the CPU and the memory if each sprite was a different object. So the sprite is created once and then is rendered at different locations in the screen. This problem can be solved using the flyweight pattern. The object that renders the sprite is a flyweight.

## Cost

There are several implementations for this pattern. So it's up to you to find a cheap implementation. Only implement this pattern if you have or will have CPU or memory issues.

### Creation

This pattern is quite easy to create.

### Maintenance

This pattern is quite easy to maintain.

### Removal

This pattern is quite easy to remove too.

## Advises

* Use pre-existing tools from the language like the sets in Java.

## Implementations

The following programs illustrate the document example given above: the flyweights are called FontData in the Java example. The examples illustrate the flyweight pattern used to reduce memory by loading only the data necessary to perform some immediate task from a large Font object into a much smaller FontData (flyweight) object.
# Computer Science Design Patterns/Facade

A Facade pattern hides the complexities of the system and provides an interface to the client from where the client can access the system. Dividing a system into subsystems helps reduce complexity. We need to minimize the communication and dependencies between subsystems. For this, we introduce a facade object that provides a single, simplified interface to the more general facilities of a subsystem.

## Examples

The SCP command is a shortcut for SSH commands. A remote file copy could be done writing several commands with an SSH connection but it can be done in one command with SCP. So the SCP command is a facade for the SSH commands. Although it may not be coded in the object programming paradigm, it is a good illustration of the design pattern.

## Cost

This pattern is very easy and has not additional cost.

### Creation

This pattern is very easy to create.

### Maintenance

This pattern is very easy to maintain.

### Removal

This pattern is very easy to remove too.

## Advises

* Do not use this pattern to mask only three or four method calls.

## Implementations

This is an abstract example of how a client ("you") interacts with a facade (the "computer") to a complex system (internal computer parts, like CPU and HardDrive).
# Computer Science Design Patterns/Chain of responsibility

Various examples of the Chain of responsibility pattern.
Below is an example of this pattern in Java. A logger is created using a chain of loggers, each one configured with different log levels.
The following Java code illustrates the pattern with the example of a logging class. Each logging handler decides if any action is to be taken at this log level and then passes the message on to the next logging handler. Note that this example should not be seen as a recommendation on how to write logging classes.
Also, note that in a 'pure' implementation of the chain of responsibility pattern, a logger would not pass responsibility further down the chain after handling a message. In this example, a message will be passed down the chain whether it is handled or not.
The output is:
Below is another example of this pattern in Java. In this example we have different roles, each having a fix purchase power limit and a successor. Every time a user in a role receives a purchase request, when it's over his limit, he just passes that request to his successor.
The PurchasePower abstract class with the abstract method processRequest.
Four implementations of the abstract class above: Manager, Director, Vice President, President
The PurchaseRequest class with its Getter methods which keeps the request data in this example.
And here a usage example, the successors are set like this: Manager -> Director -> Vice President -> President
Another example:
Output
Java example about purchase power of various roles, using perl 5.10 and Moose.
Perl example using perl 5.10 and Moose.
This C# examples uses the logger application to select different sources based on the log level;
Another example:
# Computer Science Design Patterns/Decorator

The decorator pattern helps to add behavior or responsibilities to an object. This is also called “Wrapper”.

## Cost

This pattern can be very expensive. You should only use it when it is really necessary. You should have lots of different behaviors and responsibilities for the same class.

### Creation

This pattern is expensive to create.

### Maintenance

This pattern can be expensive to maintain. If the representation of a class often changes, you will have lots of refactoring.

### Removal

This pattern is hard to remove too.

## Advises

* Put the decorator term in the name of the decorator classes to indicate the use of the pattern to the other developers.

## Implementations

This example illustrates a simple extension method for a bool type.

## Coffee making scenario

The output of this program is given below:
Whip Milk Coffee Cost: 2.2
The output of this program is given below:
Cost: 1.0; Ingredients: Coffee Cost: 1.5; Ingredients: Coffee, Milk Cost: 1.7; Ingredients: Coffee, Milk, Sprinkles

## First Example (window/scrolling scenario)

The following Java example illustrates the use of decorators using the window/scrolling scenario.
The following classes contain the decorators for all Window classes, including the decorator classes themselves.
Here's a test program that creates a Window instance which is fully decorated (i.e., with vertical and horizontal scrollbars), and prints its description:
The output of this program is "simple window, including vertical scrollbars, including horizontal scrollbars". Notice how the getDescription method of the two decorators first retrieve the decorated Window's description and decorates it with a suffix.

## Second Example (coffee making scenario)

The next Java example illustrates the use of decorators using coffee making scenario. In this example, the scenario only includes cost and ingredients.
The following classes contain the decorators for all Coffee classes, including the decorator classes themselves..
Here's a test program that creates a Coffee instance which is fully decorated (i.e., with milk, whip, sprinkles), and calculate cost of coffee and prints its ingredients:
The output of this program is given below:
Cost: 1.0 Ingredient: Coffee Cost: 1.5 Ingredient: Coffee, Milk Cost: 1.7 Ingredient: Coffee, Milk, Sprinkles Cost: 2.4 Ingredient: Coffee, Milk, Sprinkles, Whip

## Coffee example
### Dynamic languages

The decorator pattern can also be implemented in dynamic languages either with interfaces or with traditional OOP inheritance.

## External links

* Java Design Patterns tutorial
* History of Design Patterns
# Circuit Theory/Phasors/proof1

    $g(t)=G_{m}cos(\omega t)$ starting point
    $g(t)=G_{m}\operatorname {Re} (e^{j\omega t})$
    $g(t)=G_{m}\operatorname {Re} (e^{j*0}e^{j\omega t})$
    $g(t)=\operatorname {Re} (G_{m}e^{j0}e^{j\omega t})$
    $g(t)=\operatorname {Re} (\mathbb {G} e^{j\omega t})$
    $\mathbb {G} =G_{m}e^{j0}=G_{m}(cos(0)+j*sin(0))=Gm$
# Circuit Theory/Phasors/proof8

    $g(t)=G_{m}sin(\omega t-\phi )$
    $g(t)=G_{m}cos(\omega t-\phi -{\frac {\pi }{2}})$
    $g(t)=G_{m}\operatorname {Re} (e^{j(\omega t-\phi -{\frac {\pi }{2}})})$
    $g(t)=G_{m}\operatorname {Re} (e^{j*(-\phi -{\frac {\pi }{2}})}e^{j\omega t})$
    $g(t)=\operatorname {Re} (G_{m}e^{j*(-\phi -{\frac {\pi }{2}})}e^{j\omega t})$
    $g(t)=\operatorname {Re} (\mathbb {G} e^{j\omega t})$
    $\mathbb {G} =G_{m}e^{j*(-\phi -{\frac {\pi }{2}})}=G_{m}(cos(-\phi -{\frac {\pi }{2}})+j*sin(-\phi -{\frac {\pi }{2}}))$
    $=G_{m}cos(-\phi -{\frac {\pi }{2}})+jG_{m}sin(-\phi -{\frac {\pi }{2}})$
    $=G_{m}(cos(-\phi )cos({\frac {\pi }{2}})+sin(-\phi )sin({\frac {\pi }{2}}))+jG_{m}(sin(-\phi )cos({\frac {\pi }{2}})-cos(-\phi )sin({\frac {\pi }{2}}))$
    $=G_{m}sin(-\phi )-jG_{m}cos(-\phi )$
    $=-G_{m}sin(\phi )-jG_{m}cos(\phi )$
# Circuit Theory/Phasors/proof2

    $g(t)=G_{m}sin(\omega t)$ starting point
    $g(t)=G_{m}cos(\omega t-{\frac {\pi }{2}})$
    $g(t)=G_{m}\operatorname {Re} (e^{j(\omega t-{\frac {\pi }{2}})})$
    $g(t)=G_{m}\operatorname {Re} (e^{-j*{\frac {\pi }{2}}}e^{j\omega t})$
    $g(t)=\operatorname {Re} (G_{m}e^{-j*{\frac {\pi }{2}}}e^{j\omega t})$
    $g(t)=\operatorname {Re} (\mathbb {G} e^{j\omega t})$
    $\mathbb {G} =G_{m}e^{-j*{\frac {\pi }{2}}}=G_{m}(cos(-{\frac {\pi }{2}})+j*sin(-{\frac {\pi }{2}}))=-jGm$
# Circuit Theory/Phasors/proof7

    $g(t)=G_{m}cos(\omega t-\phi )$
    $g(t)=G_{m}\operatorname {Re} (e^{j(\omega t-\phi )})$
    $g(t)=G_{m}\operatorname {Re} (e^{-j*\phi }e^{j\omega t})$
    $g(t)=\operatorname {Re} (G_{m}e^{-j*\phi }e^{j\omega t})$
    $g(t)=\operatorname {Re} (\mathbb {G} e^{j\omega t})$
    $\mathbb {G} =G_{m}e^{-j*\phi }=G_{m}(cos(-\phi )+j*sin(-\phi ))=G_{m}cos(\phi )-jG_{m}sin(\phi )$
# Circuit Theory/Phasors/j omega disappears

What makes $e^{j\omega }$ of $g(t)=\operatorname {Re} (G_{m}e^{j\phi }e^{j\omega t})$ disappear?
First express voltage and current separately:
    $v(t)=\operatorname {Re} (V_{m}e^{j\phi }e^{j\omega t})$
    $i(t)=\operatorname {Re} (I_{m}e^{j\phi }e^{j\omega t})$
Every voltage in the Loop equations will have the $e^{j\omega }$ term in it so it can be canceled out.
    $V_{m1}e^{j\phi _{1}}e^{j\omega t}+V_{m2}e^{j\phi _{2}}e^{j\omega t}+V_{m3}e^{j\phi _{3}}e^{j\omega t}=V_{s}e^{j\phi _{s}}e^{j\omega t}$
    $V_{m1}e^{j\phi _{1}}{\cancel {e^{j\omega t}}}+V_{m2}e^{j\phi _{2}}{\cancel {e^{j\omega t}}}+V_{m3}e^{j\phi _{3}}{\cancel {e^{j\omega t}}}=V_{s}e^{j\phi _{s}}{\cancel {e^{j\omega t}}}$
    $V_{m1}e^{j\phi _{1}}+V_{m2}e^{j\phi _{2}}+V_{m3}e^{j\phi _{3}}=V_{s}e^{j\phi _{s}}$
    $\mathbb {V} _{m1}+\mathbb {V} _{m2}+\mathbb {V} _{m3}=\mathbb {V} _{s}$
Every current in the Junction (node) equations will have the $e^{j\omega }$ term in it so it can be canceled out.
    $I_{m1}e^{j\phi _{1}}e^{j\omega t}+I_{m2}e^{j\phi _{2}}e^{j\omega t}+I_{m3}e^{j\phi _{3}}e^{j\omega t}=I_{s}e^{j\phi _{s}}e^{j\omega t}$
    $I_{m1}e^{j\phi _{1}}{\cancel {e^{j\omega t}}}+I_{m2}e^{j\phi _{2}}{\cancel {e^{j\omega t}}}+I_{m3}e^{j\phi _{3}}{\cancel {e^{j\omega t}}}=I_{s}e^{j\phi _{s}}{\cancel {e^{j\omega t}}}$
    $I_{m1}e^{j\phi _{1}}+I_{m2}e^{j\phi _{2}}+I_{m3}e^{j\phi _{3}}=I_{s}e^{j\phi _{s}}$
    $\mathbb {I} _{m1}+\mathbb {I} _{m2}+\mathbb {I} _{m3}=\mathbb {I} _{s}$
# Circuit Theory/Phasors/proof6

    $g(t)=G_{m}sin(\omega t+\phi )$
    $g(t)=G_{m}cos(\omega t+\phi -{\frac {\pi }{2}})$
    $g(t)=G_{m}\operatorname {Re} (e^{j(\omega t+\phi -{\frac {\pi }{2}})})$
    $g(t)=G_{m}\operatorname {Re} (e^{j*(\phi -{\frac {\pi }{2}})}e^{j\omega t})$
    $g(t)=\operatorname {Re} (G_{m}e^{j*(\phi -{\frac {\pi }{2}})}e^{j\omega t})$
    $g(t)=\operatorname {Re} (\mathbb {G} e^{j\omega t})$
    $\mathbb {G} =G_{m}e^{j*(\phi -{\frac {\pi }{2}})}=G_{m}(cos(\phi -{\frac {\pi }{2}})+j*sin(\phi -{\frac {\pi }{2}}))$
    $=G_{m}cos(\phi -{\frac {\pi }{2}})+jG_{m}sin(\phi -{\frac {\pi }{2}})$
    $=G_{m}(cos(\phi )cos({\frac {\pi }{2}})+sin(\phi )sin({\frac {\pi }{2}}))+jG_{m}(sin(\phi )cos({\frac {\pi }{2}})-cos(\phi )sin({\frac {\pi }{2}}))$
    $=G_{m}sin(\phi )-jG_{m}cos(\phi )$
# Circuit Theory/Phasors/proof5

    $g(t)=G_{m}cos(\omega t+\phi )$
    $g(t)=G_{m}\operatorname {Re} (e^{j(\omega t+\phi )})$
    $g(t)=G_{m}\operatorname {Re} (e^{j*\phi }e^{j\omega t})$
    $g(t)=\operatorname {Re} (G_{m}e^{j*\phi }e^{j\omega t})$
    $g(t)=\operatorname {Re} (\mathbb {G} e^{j\omega t})$
    $\mathbb {G} =G_{m}e^{j*\phi }=G_{m}(cos(\phi )+j*sin(\phi ))=G_{m}cos(\phi )+jG_{m}sin(\phi )$
# C Programming/Language overloading and extensions

Most C compilers have one or more "extensions" to the standard C language, to do things that are inconvenient to do in standard, portable C.
Some examples of language extensions:
* in-line assembly language
* interrupt service routines
* variable-length data structure (a structure whose last item is a "zero-length array").
* re-sizeable multidimensional arrays
* various "#pragma" settings to compile quickly, to generate fast code, or to generate compact code.
* bit manipulation, especially bit-rotations and things involving the "carry" bit
* storage alignment
* Arrays whose length is computed at run time.

## External links

* GNU C: Extensions to the C Language
* C/C++ interpreter Ch extensions to the C language for scripting
* SDCC: Storage Class Language Extensions
* ↑ comp.lang.c FAQ list: Question 2.6: "C99 introduces the concept of a flexible array member, which allows the size of an array to be omitted if it is the last member in a structure, thus providing a well-defined solution."
# C Programming/MS Windows Reference
## Header files

| alloc.h | Dynamic memory allocation. |
| conio.h | Text user interfaces. |
| process.h | Threads and processes. |

## Table of functions
### alloc.h

* farmalloc

### conio.h

* getch
* getche
* gotoxy
* clrscr
# C Programming/MS Windows Reference/conio.h

conio.h is a C header file used in old MS-DOS compilers to create text user interfaces. It is not described in The C Programming Language book, and it is not part of the C standard library, ISO C nor is it required by POSIX.
This header declares several useful library functions for performing "console input and output" from a program. Most C compilers that target DOS, Windows 3.x, Phar Lap (company)|Phar Lap, DOSX, OS/2, or Win32 have this header and supply the associated library functions in the default C library. Most C compilers that target UNIX and Linux do not have this header and do not supply the library functions. Some embedded systems are using a conio-compatible library.
The library functions declared by conio.h vary somewhat from compiler to compiler. As originally implemented in Lattice C, the various functions mapped directly to the first few DOS int 21h functions. But the library supplied with Borland's Turbo C did not use the DOS API but instead accessed video RAM directly for output and used BIOS interrupt calls; they also have additional functions inspired on the successful Turbo Pascal library.
Compilers that targeted non-DOS operating systems, such as Linux, Win32 and OS/2, provided different implementations of these functions. The version done by DJ Delorie for the DJGPP|GO32 extender is particularly extensive. Another example is SyncTERM#Libraries | SyncTERM's ciolib.
lpc
| int kbhit(void) | Determines if a keyboard key was pressed. |
| int getch(void) | Reads a character directly from the console without buffer, and without echo. |
| int getche(void) | Reads a character directly from the console without buffer, but with echo. |
| int ungetch(int c) | Puts the character c back into the keyboard buffer. |
| char *cgets(char *buffer) | Reads a string directly from the console. |
| int cscanf(char *format, arg0,... argn) | Reads formatted values directly from the console. |
| int putch(int c) | Writes a character directly to the console. |
| int cputs(const char *string) | Writes a string directly to the console. |
| int cprintf(const char *format, arg0,... argn) | Formats values and writes them directly to the console. |
Compilers provided later than 1989 have prepended an _ to the names, to comply with the requisites of the ANSI C Standard.

## External links

* Digital Mars's documentation
* IO FAQ - explanation and suggestions for non-standard console IO
* Borland-style CONIO implementation for MinGW/Dev-C++
* List of ways to get raw keyboard input

## References

* ↑ "Console and Port I/O in MSDN".
* ↑ "MicroVGA conio Text User Interface Library".
* ↑ "DJGPP C Library Reference - conio".
# C Programming/Index

This is an alphabetical index of the book.

## A

* argv - poorly treated
** C Programming/Pointers and arrays/
* Arrays
* Assignment
** C Programming/Variables/
** C Programming/Simple math/
* auto

## B

* Boolean
** C Programming/Control
* break

## C

* calloc
* case
* Cast operators
* char
** C Programming/Variables/
* Comments
* Comparison
* Compiling
* const
* continue
* Conditionals
* Control structures

## D

* Data types
** Variables
** Complex types
* default
* do
* #define
* double
** C Programming/Variables/

## E

* else
* #else
* #elif
* #endif
* #error
* extern

## F

* Files
* float
** C Programming/Variables/
* for
* free
* Functions
* Variadic functions

## G

* goto

## I

* if
* #if
* #ifdef
* #ifndef
* #include
* Input and output
** Simple input and output
** File IO
* int
** C Programming/Variables/

## L

* Logical operators
** C Programming/Simple math/
** C Programming/Control
* long
** C Programming/Variables/
* Loops

## M

* Macros
* main - poorly treated
** C Programming/Pointers and arrays/
* malloc
* Math
** Simple math - addition, subtraction, multiplication, division, and modulus
** Further math - functions from math.h library
* Memory management
* Multidimensional arrays
** C Programming/Common practices/

## O

* Operator
** Simple math
** C Programming/Reference Tables/

## P

* #pragma
* Preprocessor
* printf
** C Programming/Simple input and output/
** C Reference/stdio.h/printf
** Procedures and functions/printf
* Pointers
** Pointers and arrays
** C Programming/Complex types/
* Procedures

## R

* ralloc
* register
* return

## S

* short
** C Programming/Variables/
* signed
** C Programming/Variables/
* sizeof
* Standard libraries
** Standard libraries
** C Programming/Procedures and functions/
** C Reference/assert.h
** C Reference/complex.h
** C Reference/ctype.h
** C Reference/errno.h
** C Reference/fenv.h
** C Reference/float.h
** C Reference/inttypes.h
** C Reference/iso646.h
** C Reference/limits.h
** C Reference/locale.h
** C Reference/math.h
** C Reference/setjmp.h
** C Reference/signal.h
** C Reference/stdarg.h
** C Reference/stdbool.h
** C Reference/stddef.h
** C Reference/stdint.h
** C Reference/stdio.h
** C Reference/stdlib.h
** C Reference/string.h
** C Reference/tgmath.h
** C Reference/time.h
** C Reference/wchar.h
** C Reference/wctype.h
* static
* Static functions
* Strings
* struct
* Subprograms
* switch

## T

* typedef - seems poorly treated

## U

* #undef
* union
* unsigned
** C Programming/Variables/

## V

* Variable-length argument lists
* Variadic functions
* volatile

## W

* while

## Variables

* Variables
# C Programming/Links

Links to online resources relating to learning how to program in C:
* The C Book, second edition by Mike Banahan, Declan Brady and Mark Doran, originally published by Addison Wesley in 1991. This version is made freely available.
* Programming in C: A Tutorial, by Brian W. Kernighan; 9600 words
* The GNU C Reference Manual -- a reference for the C programming language, as implemented by the GNU C Compiler
* The GNU C Library -- a manual for the GNU C library, which defines all of the library functions specified by the ISO C standard, and other functions
* Wikipedia:C syntax - cca 9700 words, as of March 2012
* Wikipedia:C (programming language)
* Jones, Derek M. The New C Standard: A Cultural and Economic Commentary (PDF). Addison-Wesley. ISBN 0-201-70917-1.
Printed books and materials:
# Abstract Algebra/Group Theory/Homomorphism/Kernel of a Homomorphism is a Normal Subgroup
## Theorem

Let f be a homomorphism from group G to group K. Let e$_K$ be identity of K.
    ${\text{ker}}~f$ is a normal subgroup.

## Proof

$f(g\ast n\ast g^{-1})=f(g)\circledast f(n)\circledast f(g^{-1})=f(g)\circledast e_{K}\circledast f(g^{-1})=f(g)\circledast f(g^{-1})=f(g\ast g^{-1})=f(e_{G})=e_{K}$