OpenLLM-France/wikimedia huggingface dataset:
# General Engineering Introduction/Form Function
## Form

For Plato, human beings live in a world of visible and intelligible things. The visible world is what surrounds us: what we see, what we hear, what we experience. The visible world is full of objects that are primarily influenced by other local objects. Asteroids colliding in another galaxy do not cause us to sneeze. Local objects cause each other to change and this causes uncertainty.
Intelligible things or objects can be understood. Plato believed that everything can be understood. We may not understand it now. Understanding means unchanging human reasoning. Anything arising from reason alone, such as abstract definitions or mathematics, makes up this intelligible world. This is reality. The intelligible world contains eternal "Forms" (in Greek, idea) of things. The visible world is the imperfect and changing manifestation in this world of these unchanging forms. For example, the "Form" or "Idea" of a horse is intelligible, abstract, and applies to all horses. The Horse Form never changes, even though horses vary wildly among themselves—the Horse Form would never change even if every horse in the world were to vanish. An individual horse is a physical, changing object that can easily cease to be a horse (if, for instance, it's dropped out of a fifty story building); the Form of a horse, or "horseness," never changes. As a physical object, a horse only makes sense in that it can be referred to the "Form" or "Idea" of horseness.
For more, read this wikipedia form article.

## Function

A google search of Form and Function does not result in a link to greek philosophy. Notice all the links claiming form and function are advertisements claiming:
* beauty
* feel
* no need for a manual
* obvious how it works
Most expect form and function to be related. Marketing and sales almost require them to be related in an obvious way. Anything too new, (unique form) may never sell even if it is the best thing since sliced bread.
There is another whole world of special products that engineers sell other engineers, scientists and technicians. These products may be kludgy, they may not be elegant. They may be puzzles of function. When is it necessary to make a combination of buttons, knobs, and software something a four year old can understand? When is it time to evolve the product's function rather than it's form?

## Form Follows Function

Read the following: form follows function.

## Form Factor

Read the following: form factor.
# General Engineering Introduction/Golden Ignorance/attitude

If an introduction to engineering course seems perverse:
    Student "I can not get the arduino to blink."
    Teacher "That is wonderful."
    Student "Will you help me?"
    Teacher "Why would I interrupt your joy?"
    Student "I am in pain,, not joy. Everyone else can get it to blink. Will someone show me? I must be an idiot."
    Teacher "Do you think there are others like yourself in the world?"
    Student "Probably."
    Teacher "Do you want to help those like yourself?"
    Student "I guess so."
    Teacher RANT "Suppose I or someone else shows you how. Will you still remember the feelings, the symptoms, the wrong starting place, the errors? Will you have a chance of putting these into words so others like yourself don't have to suffer? Can you turn your pain into opportunity, life and joy? Can you make this the world's problem and not yours? Can you fix the world? Do you want to be an engineer?"
    Student "Can't you help me?"
    Teacher "No .. document your gold. Turn your agnst into advice for someone like yourself."
    Student "Why aren't you teaching me anything?"
    Teacher "I am teaching you engineering."
    Student "What is the point in paying tuition, just to be tortured? Why don't I just learn on my own?"
    Teacher "Now we are on the right track. Suppose you figure something out on your own. Does this make you an engineer?"
    Student "I guess yes."
    Teacher "No. Why not?"
    Student "I have to document something."
    Teacher "Yes!"
    Student "Why?"
    Teacher "Trades, Crafts are almost engineering, but are not because there is no documentation. Information, training is passed down by word of mouth, not by creating documents that speak for themselves. Once you start documenting what you learn, you are engineering!"
    Student "This is nuts."
    Teacher "Do you want to be normal?"
# Haskell/Solutions/Type basics

← Back to Type basics
* Exercises
* Try using :type on the literal value "H" (notice the double quotes). What happens? Why?
* Try using :type on the literal value 'Hello World' (notice the single quotes). What happens? Why?
* "H" is a String with just one element.
* 'Hello World' is invalid because Chars consist of only one character.
* Exercises
* What are the types of the following functions? For any functions involving numbers, you can just pretend the numbers are Ints.
* The negate function, which takes an Int and returns that Int with its sign swapped. For example, negate 4 = -4, and negate (-2) = 2
* The (||) function, pronounced 'or', that takes two Bools and returns a third Bool which is True if either of the arguments were, and False otherwise.
* A monthLength function which takes a Bool which is True if we are considering a leap year and False otherwise, and an Int which is the number of a month; and returns another Int which is the number of days in that month.
* f x y = not x && y
* g x = (2*x - 1)^2
* negate :: Int -> Int
* || :: Bool -> Bool -> Bool
* monthLength :: Bool -> Int -> Int
And in the second round:
* f :: Bool -> Bool -> Bool
* g :: Int -> Int
# Haskell/Solutions/Simple input and output

← Back to Simple input and output

## Back to the real world

* Exercises
* Back in the Type Basics chapter, we mentioned that the type of the openWindow function had been simplified. What do you think its type should actually be?
Back in Type Basics, we said:
   You need to open a new window which contains all the options that they can change. Let's look at the type signature for this function:
Opening a window, however, implies not just creating it but also drawing it on the screen. The result, therefore, has to have an IO type, just like putStrLn has. The real signature should be:
A real example of an openWindow function with such a signature (except for slightly different names) can be found in the HGL package.

## Sequencing actions with do

* Exercises
* Write a program which asks the user for the base and height of a
* right angled triangle, calculates its area and prints it to the screen. The
* interaction should look something like:
* The base?
* 3.3
* The height?
* 5.4
* The area of that triangle is 8.91
* Hint: you can use the function read to convert user strings like "3.3" into numbers like 3.3 and function show to convert a number into string.
Note that the return type for read is inferred from the type of the expression it is in. 0.5*read("10.0") evaluates to 5.0, as expected. read("10.0") results in an error. In such cases a numeric type must be specified: read "10.0" ::Double, for example.

### Controlling Actions

* Exercises
* Write a program that asks the user for his or her name. If the name is
* one of Simon, John or Phil, tell the user that you think Haskell is a
* great programming language. If the name is Koen, tell them that you
* think debugging Haskell is fun (Koen Classen is one of the people who
* works on Haskell debugging); otherwise, tell the user that you don't
* know who he or she is.
* (As far as syntax goes there are a few different ways to do it; write at least a version using if / then / else.)
With if-statements:
An alternative using a where block:

## Actions under the microscope

* Exercises
* Why does the unsweet version of the let binding require an extra do keyword?
* Do you always need the extra do?
* (extra credit) Curiously, let without in is exactly how we wrote things when we were playing with the interpreter at the beginning of this book. Why can you omit the in keyword in the interpreter, when you'd have to put it in when typing up a source file?
* A let name = value in thing binding has the same type as thing. Because we want the binding to be an IO action, the thing needs to be an IO action, so we need a do keyword.
* No, not always. Just as in "normal" code, you can omit the do keyword if there's only one IO action following it.
* The GHCi interpreter is like one big do-block with some extra magic, so that it converts normal expressions to IO-actions. As in any do-block, you can omit the in keyword.
# Haskell/Solutions/Next steps

← Back to Next steps

## Introducing pattern matching

* Exercises
* We cheated a little when moving from the second version of pts to the third one: they do not do exactly the same thing. Can you spot what the difference is?
The difference is what happens when the argument is smaller than 1. In both the second and the third versions, they will be matched only on the final cases (by the catch-all patterns _ and x, respectively). In the second version, the final case evaluates to 0 at once. In the third version, however, there is also the x <= 6 guard, which is evidently true when the argument is less than 1; and thus the result will be 7 - x. Thus, pts (-4) for instance evaluates to 0 with the second version but to 11 with the third version.
N.B.: In a footnote to the text we claimed that for this example we wouldn't be too worried about what should happen if pts was given nonsensical inputs; still, corner cases like this are the sort of issue that tends to trip us up when writing "real" code. In other words: it might make a difference in your program, so stay alert.
Here is a variation of the third version which is exactly equivalent to the second one:
# Haskell/Solutions/Pattern matching

← Back to Pattern matching

## Matching literal values

* Exercises
* Test the flawed h function above in GHCi, with arguments equal to and different from 1. Then, explain what goes wrong.
* In this section about pattern matching with literal values, we made no mention of the boolean values True and False, but we can do pattern matching with them as well, as demonstrated in the Next steps chapter. Can you guess why we omitted them? (Hint: is there anything distinctive about the way we write boolean values?)
1.
When used for pattern matching, a simple variable name like the k in
binds k to the argument of h and, crucially, matches anything at all. Since we are not using the bound k variable in the right hand side of the equation, in this function the effect of this definition is the same of
Which is why GHC/GHCi complains about overlapping patterns, and why the second equation for h gets ignored. Also, the k = 1 definition made outside of the function has no influence on what happens - the k used in pattern matching has local scope (that of the h equation), and has nothing to do with that other k.
2.
Bool is not a literal value; rather, it is an algebraic datatype like the ones we first met in the previous chapter. In essence, its definition in Prelude amounts to simply:
False and True are parameterless constructors; and that is why their names start with a capital letter.

## Syntax tricks

* Exercises
* Implement scanr, as in the exercise in Lists III, but this time using an as-pattern.
You probably used head instead of an as-pattern in the first version of this exercise; here, on the other hand, we do not match the empty list in the pattern for ys. In this specific case, neither solution is actually unsafe, because the result of myScanr will never be an empty list. Nevertheless, pattern matching still is a better choice than head, as it makes it more obvious that we chose not to handle the empty list case.
# Haskell/Solutions/Traversable

← Back to Traversable

## Functors made for walking

1.

## Interpretations of Traversable

1.
Note that this transpose behaves differently from the one in Data.List. That one will happily assemble columns of unequal length when given rows of unequal size, while our version cuts off extra elements. Neither solution is a very good one, but then nested lists are not a good representation for matrices in first place.
2.
traverse mappend t is a (Traversable t, Monoid b) => b -> t b function which monoidally appends its argument to all of the values in t. The relevant Applicative instance is the one for functions.
3.
This is the type of mapAccumL:
With a couple flips, the type becomes...
... which is equivalent to:
That strongly suggests we can write mapAccumL as a traversal with the State applicative functor. One important issue to consider is how the applicative instance of State sequences effects (for State is not commutative). Since we know that instances in the libraries sequence from left to right, we are good to go (otherwise, we would have to use Control.Applicative.Backwards to avoid ending up with mapAccumR).
.. and that's it. All that is needed is undoing the flips and adding the state/runState boilerplate.
That is just like the actual implementation in Data.Traversable. The only difference is that Data.Traversable uses an internal implementation of State to avoid importing Control.Monad.Trans.State (actually two implementations, thanks to the sequencing of effects issue).
# Haskell/Solutions/Understanding monads
### Random Number Generation

* Exercises
* Roll two dice! With sumTwoDice that is :-) . Use fst to extract the result.
* Write a function rollNDice :: Int -> Seed -> ([Int],Seed) that rolls dice n times and returns a list of the n results. Extra: If you know about infinite lists, use unfoldr and take to get the result list (but without seed this time).
* Reimplement Seed and rollDie with StdGen and random from System.Random.
* Now that you have random numbers, do some statistical experiments with the help of rollNDice. For example, do a sanity check that rollDie is not skewed and returns each number with equal likelihood. How is the sum of pips of a double dice roll distributed? The difference? And triple rolls?
2. Using randomNext , Seed and rollDie as defined in the chapter:
The function gains the first die and seed and then recursively calls itself to roll N number of die which, once RollNDice reaches the base case, in turn builds up a list of die. The function then returns the list of die and the final seed that was passed to the base case, rollNDice 0 seed = (, seed).
3. We use mkStdGen to get the computer's random number generator and we give it an arbitrary number, 232. Firstly with import System.Random at the top of your file:
In Prelude:

### Threading the State with bind

* Exercises
* Implement rollNDice :: Int -> Random [Int] from the previous subsection with >>= and return.
1. You have seen everything below the definition of (>>==) before. So everything up to that point is just there to set everything up. I've named >>= >>== and return return1 because this chapter uses bind and return to deal with random numbers specifically; whereas the real bind and return are more generalised and thus do not work for reasons that are somewhere over -----------------> there. At least it works; what more do you want from me? Blood?
With import System.Random at the top of your file:
In prelude:
In case you're wondering: You pass (mkStdGen 232111) to rollNDice1 because rollNDice 20 on its own only creates a Random1 [Int]; you need to pass the newly formed Random1 [Int] a seed, in the form of (mkStdGen 242), to get it shooting out random numbers.

### Input/Output needs bind

* Exercises
* Write a function putString :: String -> IO that outputs a sequence of characters with the help of putChar.
* The program
* loop :: IO
* loop = return >> loop
* loops forever whereas
* loopX :: IO
* loopX = putChar 'X' >> loopX
* prints an infinite sequence XXXXXX... of X-s. Clearly, a user can easily distinguish them by looking on the screen. However, show that the model IO a = World -> (a, World) gives the same denotation ⊥ for both. This means that we have to abandon this model as possible semantics for IO a.
1.

### The State Monad

* Exercises
* Correct the definition for (>>=) to take the State constructor into consideration. You'll need to use pattern matching to remove the State constructor.
* Exercises
* Slightly rewrite your definition of (>>=) to use runState instead of pattern-matching on State
# Haskell/Solutions/Variables and functions

← Back to Variables and functions
* Exercises
* Explain how GHCi evaluates quadruple 5.
* Define a function that subtracts 12 from half its argument.
* Exercises
* Write a function to calculate the volume of a box.
* Approximately how many stones are the famous pyramids at Giza made up of? Use GHCi for your calculations.
One approach for the Giza problem is starting from the pyramid volume and the estimated stone volume. Using general functions for the task, that might look like this in GHCi:
* Exercises
* Write a function to calculate the volume of a cylinder.
# Haskell/Solutions/Understanding arrows

← Back to Understanding arrows

## Pocket guide to Arrow

1.
2.
3.
# German/Level I/Review 3

Review Section I.C: Lessons I.7 to I.9
Here is a review of what we have learnt;

## Vocabulary

Here is the vocabulary we have learnt.

### Clothes

We have learnt about the clothes we wear.

### Shops

We have learnt about shops.

#### Gifts and objects

We have learnt about gifts and objects sold in shops.

### Clothes

You should now know what different clothes are called.

### Material

We have learnt about different materials. Cotton Die Baumwolle Leather Das Leder Rayon Die Kuntseide

### Is it cheap?!

We have learnt how to say if something is cheap or expensive.

### Describe

We have learnt how to say something is ugly or pretty and how it feels and looks.

### Colour

We have learnt about how to describe what colour things are.

### Family

We have learnt what relatives are called.
# German/Level I/Review 4

Review Section I.D: Lessons I.10 - I.12
# German/Level I/Vocabulary

<< Beginning German | Basic German | Intermediate German
Appendix 9 ~ Vocabulary for Level One
# German/Level I/Volk und Familie/Problems

Introduction - Lesson 4 - Lesson 5 - Lesson 6
Problems - Answers - Test - Test Answers

## Die Familie

Karl ist der _____ von Thomas.
Bettina ist die Mutter von ______.
Marie ist die ______ von Oma Lieschen.
Opa Rudolf ist der _____ von Marie.
Answers >>
# German/Level I/Review 5

Review Section I.E: Lessons I.13 to I.15
# German/Level I/Volk und Familie/Answers

Introduction - Lesson 4 - Lesson 5 - Lesson 6
Problems - Answers - Test - Test Answers

## Die Familie

Karl ist der Vater von Thomas.
Bettina ist die Mutter von Thomas/Marie.
Marie ist die Enkelin von Oma Lieschen.
Opa Rudolf ist der Opa/Großvater von Marie.
# German/Level I/Wetter

Lesson I.12: Wetter

## Dialoge

Lukas calls his friend Nadja after he sees the weather forecast.
| Lukas | Was für ein Dreckswetter die heute mal wieder in der Wettervorhersage angekündigt haben! |
| Nadja | Was für ein Wetter soll es denn geben? |
| Lukas | Es soll heute regnen. |
| Nadja | Hattest du was vor? |
| Lukas | Ja, ich wollte in die Stadt gehen, um einen Mantel zu kaufen. |
| Nadja | Es kommt noch schlimmer! |
| Lukas | Wieso? |
| Nadja | Es wird nämlich zuerst regnen und dann bekommen wir Schneefall. |
| Lukas | Boah nee! Die Straßen werden dann vereist sein. |
| Nadja | Na ja, ich muss jetzt zur Schule. Tschau Lukas! |
| Lukas | Tschau! |

## Weather
### Vocabulary

Vocabulary: weather — das Wetter  (missing file: File:German Vocabulary - weather.ogg, how to upload audio) :
| informal for: bad weather | das Sauwetter (lit. sow weather) |
| | das Dreckswetter (lit. dirty weather) |
| | das Scheißwetter (lit. shit weather) |
| weather forecast | die Wettervorhersage* |
| sun | die Sonne* |
| sunny with some clouds | heiter (you'll hear it in the weather forecast) |
| rainbow | der Regenbogen |
| starlit | sternenklar |
| fog | der Nebel* |
| frost | der Frost* |
| wind | der Wind* |
| storm | der Sturm* |
| thunderstorm | das Gewitter* |
| bad weather | das Unwetter |
| thunder | der Donner* |
| lightning | der Blitz* |
| cloud | die Wolke* |
| overcast | bedeckt* |
| precipitation | der Niederschlag |
| rain | der Regen* |
| rain shower | der Regenschauer* |
| rainy | regnerisch* |
| (to) rain cats and dogs | in Strömen regnen |
| pour down | schütten |
| drizzle | der Niesel* |
| snow | der Schnee* |
| snow falling | der Schneefall* |
| snowy | verschneit* |
| sleet | der Schneeregen* |
| low snow falling | der Schniesel (in some regions of Germany) |
| hail | der Hagel* |
| graupel | der Graupel* |
| black ice | das Glatteis* |
You will need to know each expression with an asterisk (*) after it. The others, of course, would be useful to know for the weather forecast or when someone talks with you about weather. But you aren't forced to know Schniesel. Because many people don't know this word.

### Common Phrases

Wie ist (denn) das Wetter in Berlin?
What's the weather like in Berlin?
In Berlin scheint die Sonne.
The sun shines in Berlin.
Wie wird das Wetter?
What's the weather going to be like?
Können Sie mir sagen wie das Wetter heute wird?
Can you tell me how today's weather is going to be?
Wird es regnen, oder bleibt es schön?
Will it rain, or will it remain nice?
Es wird heute schlechtes Wetter erwartet. Nimm bitte deinen Regenschirm mit!
Bad weather is today expected. Please take your umbrella with you!
Wie viel Grad zeigt das Thermometer an?
How many degrees on the thermometer?
Das Thermometer zeigt 15 Grad (Celsius) an.
The thermometer says 15 degrees (Celsius).
Das Thermometer zeigt minus 15 Grad (Celsius)* an.
The thermometer says minus 15 degrees (Celsius).
* You can also say Das Thermometer zeigt 15 Grad minus an.
# Hobo travel journalism/With a backpack around the planet (rubric in the newspaper “Southern Capital”)

“With a backpack around the planet” is one of several titles for the travel rubric in the Simferopol newspaper “Southern Capital”, whose columnist was the Crimean travel journalist Viktor Pinchuk.
Date of first publication, October 2007; a total of nine articles have been published, four of which are freely available on Wikisource (in Russian and English).

## Articles

* Легко ли живётся простому человеку в столице Крыма и столице Египта? — 28.09.2007. — № 39 (820);
* Забытая нами страна — 16.10.2007. — № 48 (822);
* Индия. Страница из путевого дневника — 26.10.2007. — № 43 (824);
* Почему эфиопы не любят фотографов, или Цена эфиопской души — 23.05.2008. — № 20 (853);
* А вы бывали на озере Кьога... в Уганде? — 20.06.2008. — № 24 (857);
* Что такое МОСАРЕТУ, а также о комфорте по-африкански — 19.09.2008. — № 37 (870);
* В «обезьянник» — по собственному желанию — 23.07.2021. — № 28 (1500) — there is an English translation available;
* Ограбление по-африкански — 6.08.2021. — № 30 (1502) — there is an English translation available;
* В поисках древнего клада — 13.08.2021. — № 31 (1503) — there is an English translation available.
# History of wireless telegraphy and broadcasting in Australia/Topical/Publications/Australasian Radio World/Issues/1941 06
## P.03 - Contents Banner

The Australasian Radio World
Incorporating the
All-Wave All-World DX News
Vol. 4. - MARCH, 1940 - No. 10.

## P.03 - Contents

Nil (to save space)

## P.03 - Publication Notes

The "Australasian Radio World" is published monthly by A. G. Hull. Editorial offices, 117 Reservoir Street, Sydney, N.S.W. Telephone MA2455.
Subscription rates: 1/- per copy, 10/6 per year (12 issues) post free to Australia and New Zealand.
Printed by Bridge Printery Pty. Ltd., 117 Reservoir Street, Sydney, N.S.W., for the proprietor of the "Australasian Radio World," 117 Reservoir St., Sydney (Footnote P.44)

## P.03 - Editorial Notes

Editorial Notes
Nil