OpenLLM-France/wikimedia huggingface dataset:
# IB Mathematics (HL)/Matrices

Matrices are no longer in the Mathematics HL course. It is now found in Topic 1: Linear algebra of the Further Mathematics HL course.
# IB Mathematics (HL)/Probability

Probability is the study and quantification of chance.
There are links to Binomials.
# IB Mathematics (HL)/Calculus

Calculus is the study of rates of change. It involves differentiation and integration.
Basic differentiation and its applications:
* Differentiation from first principles
* Rules of differentiation
* Interpreting derivatives and second derivatives
* Trigonometric functions
* The exponential and natural logarithm functions
If you want more information, check out for some more information from the 1998 sylabus.
# IB Mathematics (HL)/Discrete Mathematics
## Topic 11. Discrete Mathematics
#### Natural Numbers

Whole numbers from 1 and above: {1, 2, 3...}
# GLSL Programming/GLUT/Two-Sided Smooth Surfaces

This tutorial covers two-sided per-pixel lighting (i.e. two-sided Phong shading).
Here we combine the per-pixel lighting discussed in the tutorial on smooth specular highlights with the two-sided lighting discussed in the tutorial on two-sided surfaces.

### Shader Coder

The required changes to the code of the tutorial on smooth specular highlights are: new properties for the back material, new local variables for the material parameters in the fragment shader, which are set either to the front material parameters or the back material parameters according to gl_FrontFacing. Also, the surface normal vector is negated in case a back face is rendered. Furthermore, back-face culling has to be deactivated as described in the tutorial on transparency. It's actually quite straightforward.
The vertex shader could look like this:
And the fragment shader could be:

### Summary

Congratulations, you have reached the end of this short tutorial. We have seen:
* How two-sided surfaces can be rendered with per-pixel lighting.

### Further Reading

If you still want to know more
* about the shader version for single-sided per-pixel lighting, you should read the tutorial on smooth specular highlights.
* about the shader version for two-sided per-vertex lighting, you should read the tutorial on two-sided surfaces.
< GLSL Programming/GLUT
| Back to OpenGL Programming - Lighting section | Back to GLSL Programming - GLUT section |
# GLSL Programming/HTML5

HTML5 includes support of WebGL in the canvas element. A good introduction with many examples is available in the LearningWebGL blog.
< GLSL Programming
# GLSL Programming/GLUT/Two-Sided Surfaces

This tutorial covers two-sided per-vertex lighting.
It's part of a series of tutorials about basic lighting in OpenGL. In this tutorial, we extend the tutorial on specular highlights to render two-sided surfaces. If you haven't read the tutorial on specular highlights, this would be a very good time to read it.

### Two-Sided Lighting

As shown by the figure to the left, it's sometimes useful to apply different colors to the two sides of a surface. In the tutorial on cutaways, we have seen how a fragment shader can use the built-in variable gl_FrontFacing to determine whether a fragment is part of a front-facing or a back-facing triangle. Can a vertex shader also determine whether it is part of a front-facing or a back-facing triangle? The answer is a clear: no! One reason is that the same vertex can be part of a front-facing and a back-facing triangle at the same time; thus, whatever decision is made in the vertex shader, it is potentially wrong for some triangles. If you want a simple rule to remember: “Fragments are either front-facing or back-facing. Vertices are bi.”
Thus, two-sided per-vertex lighting has to let the fragment shader determine, whether the front or the back material color should be applied. For example, with this fragment shader:
On the other hand, this means that the vertex shader has to compute the surface lighting twice: for a front face and for a back face. Fortunately, this is usually still less work than computing the surface lighting for each fragment.

### Vertex Shader Code

The vertex shader code for two-sided per-vertex lighting is a straightforward extension of the code in the tutorial on specular highlights. However, we have to deactivate back-face culling as described in the tutorial on transparency. Furthermore, the shader requires two sets of material parameters (front and back), which could be available as gl_FrontMaterial and gl_BackMaterial. With these two sets of parameters, the vertex shader could compute two colors, one for front faces and one for back faces, where the negated normal vector has to be used for the back faces. Both colors are handed to the fragment shader, which decides which color to apply. The vertex shader code is then:
The fragment shader code is described above.

### Summary

Congratulations, you made it to the end of this short tutorial with a long shader. We have seen:
* Why a vertex shader cannot distinguish between front-facing and back-facing vertices (because the same vertex might be part of a front-facing and a back-facing triangles).
* How to compute lighting for front faces and for back faces in the vertex shader.
* How to let the fragment shader decide which color to apply.

### Further Reading

If you still want to know more
* about the shader version for single-sided surfaces, you should read the tutorial on specular highlights.
* about front-facing and back-facing triangles in GLSL, you should read the tutorial on cutaways.
< GLSL Programming/GLUT
| Back to OpenGL Programming - Lighting section | Back to GLSL Programming - GLUT section |
# GLSL Programming/Irrlicht

The Irrlicht Engine supports GLSL shaders via its irr::video::IGPUProgrammingServices class. A tutorial shows how to use the class.
< GLSL Programming
# GLSL Programming/OGRE

OGRE supports GLSL shaders in its material scripts.
< GLSL Programming
# Old English/Vocabulary/Verbs

Introduction: Introduction - Grammar - Orthography - I-mutation Grammar: Nouns - Pronouns - Articles - Adjectives - Numbers - Verbs - Participles - Adverbs - Conjunctions - Prepositions - Interjections - Appositives - Word Formation -

## Movement

* come - cuman
* go - gān
* wander - ƿandrian, sƿīcan
* do - dōn
* travel, journey - Faran, Sīþian
* step - stēppan

## Weak Verbs
### Class 1

* Fremman - do, accomplish
* Tǣċan - teach
* Nerian - save
* Hīeran - hear
* Aƿyrcan - do, effect
* Merian - purify, refine
* Myntan - intend

## Other verbs

* remember - Gemunan
* enjoy, make use of - brucan
* take - niman
* save, defend, shelter, guard - beorgan
* compose, write, edit - ādihtan
* arrange, set in order, regulate, direct - dihtian
* owe, to be obliged, must, should (auxiliary) - sculan
* cover / cover (up), put a cover over - ƿreon
* prepare, supply, make ready - ġearcian
* offend, scandalize - ǣsƿīcian
* marry, wed - ǣƿnian
* hate; persecute - fēoġan, feogean
* expect, await - bāsnian
* breach, break through - brēcan
# Old English/Titles and Nicknames

In Old English, title nouns usually came directly after the noun. For example: Ēadƿeard Cyning, Ælfrīc Munuc, Ƿēlund Ċild. You could also do the equivalent of the Modern English "John the King" or "Fred the Assassin", for example: se cyning Iohannes, se morðorƿyrhta Hrōþgār.
Nickname adjectives like in "John the Short" and "Richard the Great" in Old English would come directly after the noun, minus the word for "the" (unlike in Modern English), would take the weak declension, and would agree in case, gender, and number with the noun they were modifying. For example: Carl Fǣtta - Charles the Fat, Offa Lytela - Offa the Little; but in genetive: Carles Fǣttan (sƿeord) - Charles the Fat's (sword), Offan Lytelan (tæfl) - Offa the Little's (board game). Since regnal numbers (like the "II" in "Elizabeth II") don't seem to have been used in Old English, but since regnal numbers are ordinal in sense, and ordinals were grammatically adjectives in Old English, and adjectives were allowed to follow the noun (as has just been explained earlier in this paragraph), one could excuse something like "Elisabeþ II" as allowable in OE grammar.
Proper nouns, including personal nouns, could also be used with the definitive article and/or an adjective, like in Modern English "No - I don't mean that Sarah. I mean the other Sarah." For example, "se ōðer Iohannes" - "the other John (not that one)" or "John the Second". Such adjectives followed normal adjectival agreement rules.
Family names weren't really present in Anglo-Saxon culture, but one could think of them as "titles" and use the same constructions in grammar as for titles.
# Old English/Verbs/List of verbs with dative or accusative objects

Verbs which may take either dative or accusative objects.
# Old Norse

This is a reference grammar for Old Norse, a language now extinct but once spoken in Scandinavia. As this book is still under development, you are invited to make any problems/suggestions known in our Discussion page.

## Table of Contents
### Grammar

Each of the following chapters covers an aspect of the grammar of Old Norse.
* Noun Declension
* Verb Conjugation
* Adjective Declension
* Pronouns
* Numerals

### Miscellaneous

Each of the following chapters covers an aspect of Old Norse that is not about grammar, but nonetheless necessary for building a better understanding of the language and its grammar.
* Phonological changes
# Handbook of Genetic Counseling/Ewing's Sarcoma

Ewing's Sarcoma

## What is Ewing's sarcoma/PNET?

* a cancer that can start in bone or soft tissues
* most common sites for are the pelvis, the thigh, and the trunk of the body
* peak ages are 10-20, but younger children and older adults can also get it
* half are under 15 years
* less common before 5 or after 30
* no known cause
* cells in the tumours have a piece of chromosome 11 moved to chromosome 22
* 85% contain chromosomal translocation at the t(11;22)(q24;q12)
* the genetic change occurs only in the tumour cells, not in the sperm or egg
* 2.5% of cases of childhood cancer
* development of the tumour appears to be in some way related to periods in life with rapid growth, hence the average for tumour development is 14-15 years
* slightly more common in boys than in girls
* most common early signs are pain and swelling
* can spread to other parts of the body
* always requires treatment to the whole body (chemotherapy, surgery, radiation therapy)

## Symptoms

* vary from person to person depending on the location and size of the cancer
* most common symptoms are pain and swelling or tenderness in the affected area
* pain may become very intense when the tumour is located near important nerves, like in the sacrum, pelvis or spine
* swelling is often seen, especially when the log bones of the arms or legs are affected
* tiredness, fever, weight loss, and anaemia

## Notes

The information in this outline was last updated in 2002.
# Handbook of Genetic Counseling/FISH

FISH is a technique where you can identify minor changes in chromosomes with the help of fluorescent dyes called probes. These probes are highly sensitive to light. They bind with the specified target and emit signals under the fluorescent microscope and minor deletions and inversions translocations can be identified. This is widely used for prenatal diagnosis and preimplantation genetic diagnosis in identification of trisomies and other structural and numerical abnormalities.Each chromosomes has its own probe.
# Handbook of Genetic Counseling/FG Syndrome-2

FG syndrome

## Introduction

* Myself, GC, Doc
* What are they expecting today? What concerns do they have?

## Contracting

* Medical Hx/Pregnancy Hx
* Family Hx
* Physical Exam
* Suggestions for testing/diagnosis
* Answer any questions

## Medical History

* Hearing test?
* Developmental milestones
* Behavior issues, when did they start? How severe? Examples?
* Has he always been floppy?
* Constipated?

## Family Hx

* Birth defects, MR, cancer at early age, genetic conditions

## F-G syndrome

* Other names: Opitz-Kaveggia syndrome
* Definition: X-linked condition with the following characteristics
* Characteristics
** MR
** Hypotonia from birth
** Seizures
** Large head
** Cowlick of frontal hairline
** Hypertelorism
** Sensorineural deafness
** Short stature
** Imperforate anus
** Constipation
** Congenital heart defects
** Broad first toes
** Attention-seeking behaviors
* Genetics
** X-linked recessive
* Diagnosis
** clinical

## Resources

* FG syndrome Family Alliancee
    www.geocities.com/HotSprings/Spa/3687/index.html
* FAQ's about FG syndrome

## Notes

The information in this outline was last updated in 2000.
# Introduction to Programming Languages/Stack
## Stack

Perhaps, the most common variables in a program are local variables, also known as automatic variables. In our example, variables `auto_var` and `auto_const` are local variables. These variables have local scope: they only exist inside of the function they declared and they lose their values as soon as the function returns. But, why so?
Every time a function is called something called activation record (or stack frame) is created. An activation record is the portion of the stack used to store a function's data upon its call. Thus, the activation record stores the function's parameters, local variables, return address, etc. The activation record of a function only exists while the function is running. After it finishes, its activation record is destroyed, thus destroying the function data. That is why local variables lose their value every time a function ends. (Remember: static variables do not behave this way. They are not stored in the stack, but in the data or bss section).

### Stack Organization

As we showed on the picture before, the stack grows down, whereas the heap grows up. That means to say that if two objects are allocated on the stack, the address of the second object will be lower than the address of the first object.
Think of a postman delivering mail on a street. If he starts delivering people's mail from the end of the street towards its beginning, he would deliver first the mail of the people whose house number is higher. That's what happens with stack allocation: objects allocated first have higher addresses. The analogy is the same for heap allocation. The only difference is that the postman would start delivering mail from the beginning of the street and walk towards its end, thus delivering first the mail of people whose address is lower.
We give a little example below showing how it works. When we run the program below we see that the address of variable `aux_1` is greater than `aux_2`'s address, which is greater than `aux_3`'s address.
# Introduction to Programming Languages/Scoping with Blocks

Blocks are a way of solving the scoping problem. A block is a program region containing definitions of variables and that delimits the regions where these definitions apply. In C programming language, a block is created using a pair of curly braces. The beginning of the block is denoted by an open curly brace '{' and the end is denoted by a closing curly brace '}'. The block collects statements together into a single compound statements. The C code below shows two blocks. One of them defines the scope of the main function while the other (an inner block) creates a new scope inside this function. It is possible to see the definition of two variables with the same name, but inside distinct blocks.
The scope of a definition is the block containing that definition, from the point of definition to the end of the block, minus the scopes of any redefinitions of the same name in interior blocks. So, the scope of the variable 'n', defined in the line 3, begins at that line and ends at line 9. But, because there is a new definition of a variable named 'n' inside this block, the variable 'n' defined outside the inner block becomes hidden from line 5 to line 7. The same source code is presented below with the distinction of the visibility of the two variables named 'n'. The scope visibility of the first definition is represented by the letter 'A' while the scope visibility of the second definition is represented by the letter 'B'.
Many different constructs serve as blocks in different languages. The term block-structured is commonly referred to languages that use some kind of block to delimit scope. Nowadays, the majority of programming languages are block-structured and few people bother to make this distinction.
The ML programming language uses the let construct to define a block. The following source code shows an example of it use. The let construct contains definitions (located before the keyword 'in') and a region where those definitions apply (from the point of each definition to the final end). The letters 'A' and 'B' distinct the two scopes in the source code.
← Definitions and Scope Type · Scoping with Namespaces →
# Introduction to Programming Languages/Subtype Polymorphism
### Subtype Polymorphism

The set of elements of a subtype is a subset of some existing set. The parameter definition of a function supports any argument of that type or a subtype. This way, if the parameters/operands of a function/operator have subtypes, that function/operator exhibits subtype polymorphism. The Java code below illustrates the use of this kind of polymorphism.
In Java, the Object class is a superclass of all classes in Java. Every class in Java extends, directly or indirectly, from Object class. The Object class is the root of the class hierarchy in Java. In the code above, the line 2 defines a method print, which takes an Object as parameter and prints it using the method println of the System.out object. The lines from 6 to 8 show subtype polymorphic calls taking objects of String, Integer and Character as arguments. Every place where it is expected a class as parameter accepts a subclass of that class as parameter.
← Parametric Polymorphism
# Introduction to Programming Languages/Static Memory
## Static memory

When a programmer declares a global variable, such as `global_var`, `global_const`, or `global_const2`, they can go into either data or bss section, depending on whether they were initialized or not. If they were, they go into the data section. If not, they go into the bss section. Static variables work the same way as globals: they go either into the data or bss section, depending on their initialization.
Notice that the size of these segments is known at compilation time. The only difference between data and bss is initialization. It is also important to point out that global and static variables zero-initialized by the compiler go into bss. Thus, `static_var_u` goes to bss whereas `static_var` goes to data.

### Scope of static variables

Static variables behave almost global variables: while local variables lose their value every time the function exits, static variables hold their value across function calls. The following program shows this behavior:
Running the program above, we see that, despite having two variables named `store`, they are different variables. That is enough to show that the scope of static variables is not global, as we might think judging from their behavior.
# Introduction to Programming Languages/Syntax Directed Translation
### Syntax Directed Translation

A compiler is a program that converts code written in a programming language into code written in a different programming language. Typically a compiler is used to convert code written in a high-level language into machine code. Like in the case of interpreters, grammars also provide the key data structure that a compiler uses to do its work. As an example, we will implement a very simple compiler that converts programs written in our language of arithmetic expressions to the polish notation. The attribute grammar that does this job can be seen below:
In this example we dump the transformed program into a list L. The append(L1, L2, LL) predicate is true whenever the list LL equals the concatenation of lists L1 and L2. The notation [ND|LL] implements the cons operation so common in functional programming. In other words, [ND|LL] represents a list that contains a head element ND, and a tail LL. As an example of use, the execution section below shows a set of queries using our new grammar, this time implemented in a file called compiler.pl:
← Syntax Directed Interpretation · Syntax Directed Type Checking →
# Introduction to Programming Languages/Quest for Meaning

Semantics is the field concerned about the definition of meaning of programming constructs. There are several different notations to define such meaning. A few examples include:
* Operational Semantics
* Axiomatic Semantics
* Denotational Semantics
The three different techniques mentioned above provide the means to explain, in a formal way, what each syntactic element of a programming language does. By formal, we mean unambiguous and mechanizable. A definition is unambiguous if there is only one way in which it can be interpreted. It is mechanizable if we can write that definition in a machine; thus, obtaining an interpreter for the programming language.
Formalism is good for several reasons. The first is that it helps in understanding a programming language. The meaning of programs is not always obvious. Even experts struggle sometimes to understand the behavior of code. And two programs, implemented in different languages, yet very similar, can have different behaviors. For instance, let us consider the following program, implemented in C:
This program prints x = 4. Now, lets take a look into another program, this time implemented in Java:
This program prints x = 3. Surprising, isn't it? And, which program is wrong? The answer to this question is: none of them. They all do what it is expected they should do, according to their semantics. In C, the assignment x += (x = 2) is translated into something like x = (x = 2) + x. In Java, on the other hand, we get something more like tmp = x; x = 2; x = x + tmp.
We shall see how to use operational semantics to describe the meaning of a programming language. The operational semantics describes meaning via an abstract machine. An abstract machine is an interpreter, i.e., a machine. However, this machine is not made of bolts and wires. It is made of mathematics. That is where the abstract in the name comes from.
To build an abstract machine we need a data-structure to represent programs. We already know such a data-structure: it is called the syntax tree, which we produce during parsing. However, the syntax tree has many elements that do not contribute to the meaning of programs. For instance, the two semi-colon marks, in the C command x = 1; x = x + 1; do not bear much voice in the final value stored in x. In this case, the semi-colon is there to help the parser to identify the end of commands. Similarly, markers such as the parentheses in the expression x * (y + z) are already encoded in the structure of the syntax tree. We do not really need to keep track of these tokens when building an interpreter to the programming language. Therefore, when designing interpreters, we need something that we call the abstract syntax of programs. Differently than the concrete syntax, the abstract syntax contains only the essential elements to let an interpreter navigate throughout the structure of programs.
← Exhaustive Searches · An Interpreter for ML →