OpenLLM-France/wikimedia huggingface dataset:
# Pinyin/Dongguan

Special:search/Dongguan prefix:Pinyin/
Dongguan is a prefecture-level city administered by Guangdong Province, People's Republic of China. It is situated at the east of the Zhu Jiang River Mouth, and has borders with Guangzhou, Shenzhen, and Huizhou. It has an area of 2,465km$^2$, with a population of more than 8 million. Dongguan is one of the "Guangdong Four Tigers". It is an important industrial city in the Zhu Jiang Delta, and is an important city of international processing industry.
Dōngguǎn shì Zhōnghuá Rénmín Gònghéguó Guǎngdōng Shěng guǎnxiá d 1'g dìjí-chéngshì, wèiyú Zhū Jiāng Kǒu d dōngmiàn, yǔ Guǎngzhōu, Shēnzhèn, Huìzhōu jiērǎng. Miànjī 2465km$^2$, rénkǒu 800 duō wàn. Dōngguǎn shì “Guǎngdōng Sì Xiǎohǔ” zhīyī, shì Zhū Jiāng Sānjiǎozhōu d zhòngyào gōngyè chéngshì, yěshì guójì jiāgōngyè d zhòngyào chéngshì.
# Introduction

Already we have seen that we can greatly reduce the number of vertices to draw in a voxel world by only drawing visible cube faces, and even by merging adjacent faces. We can further reduce the amount of data to send to the GPU by using a geometry shader. The idea is to send the most compact representation of a voxel face to the geometry shader, and have it produce the six vertices (for the two triangles that make up a face) and any other data that we might need. We could represent a whole voxel with one vertex, but that would mean the geometry shader does not know which sides to render, so it will render all six faces, whether they are obscured or not. It is likely that drawing the obscured faces takes more GPU time than the time saved dealing with vertices by such a geometry shader. A better way is to send two vertices (A and C in the diagram below) for each face to the vertex shader from two diametrically opposed corners of that face. This way we can also represent merged faces. Knowing that the face is rectangular and lies in an x, y or z-plane, we can reconstruct the other two corners (B and D), and from the four corners we can create two triangles in a strip (BAC and ACD). It is also possible to reconstruct the normal of the face this way (using the cross product of the lines AC and AB), which we can use for lighting calculations.
Before, we had to pass the same texture coordinate in all six vertices of a face. With the geometry shader, the shader has access to both input vertices at the same time, so we only need to pass the texture coordinate in one of them. The shader can copy it to all six output vertices. That also means we can use the w coordinate of the second input vertex for something else, for example intensity information.

# Enabling geometry shading

Before using a geometry shader, we can check if it is actually supported by your GPU using GLEW:
We compile and link the geometry shader the same way as with the vertex and fragment shaders, except that we need to tell OpenGL what kind of input the geometry shader expects, and what kind of output it generates. In our case, it expects LINES as input, and produces TRIANGLE_STRIPS as output. It is done as follows:
When we draw, we just act like we draw GL_LINES, the GPU will take care of the rest.

# Creating vertices for the geometry shader

Before, in our update function, we had to generate six vertices, like so (for the faces that are viewed from the negative x direction):
We can simply modify that piece of code to generate the two vertices for our geometry shader:
Notice how we pass intensity information in the second vertex.

# Shaders

The geometry shader is as follows:
The vertex shader has nothing to do but pass on the vertices calculated by the geometry shader:
The fragment shader is as follows:

# Exercises

* Try different ways of assigning intensities to voxels.
* The fragment shader still contains an if-statement to remap the texture coordinates. Can we move that to the geometry shader?
* Is the order of the two input vertices important?
# Introduction

In the previous tutorial, you have seen how to render a chunk of voxels. However, all the voxels were drawn, even the ones that weren't visible. Also, when neighbouring voxels share the same color or texture, it is possible to merge some triangles. In this part, we will try to reduce the amount of vertices necessary by removing those that are invisible.

# Removing invisible voxel faces

In general, it is very hard to determine if a triangle is invisible for all possible camera positions. However, in our voxel world, we can be sure that one side of a voxel is invisible if there is another voxel right next to it on that side. If that is the case, we can omit drawing the two triangles that make up that voxel:
Note that this implementation only checks for visibility inside one chunk. If we have more that one chunk, then if x == 0, one should check if there is a voxel in the neighbouring chunk that could block visibility.
Exercises:
* Implement this check for the other 5 directions as well.
* Given a chunk that is completely filled (all blk[x][y][z] are non-zero), how many vertices are saved by removing the invisible ones?
* Which configuration of voxels in a chunk results in the maximum amount of vertices?
* Try rendering the chunk with GL_LINES instead of GL_TRIANGLES.

# Merging adjacent faces

Although there are various algorithms one can think of to merge adjacent triangles, a quick way is to check if we have two visible voxels in a row of the same type. If that is true, then instead of adding two new triangles, we change the two previous triangles to cover the current voxel as well. This is how it can be done:
This implementation merges faces across the inner most loop (in this case z). We keep track of the visibility of the previous voxel along the z axis and merge accordingly. It's important to note that we must now do full scans for each face in order to keep our loop variable "i" accurate and simple to use for vertex updates. As the overhead for rendering is almost entirely gpu bound, the extra loops will not hinder us too much.
The flag visible tracks whether the previous voxel was visible. If so, we can be sure that the previous two triangles in our vertex buffer do indeed belong to that voxel. Now, since our inner most for loop variable is z, we are looking at two voxels that only differ in the z coordinate. So, we should extend the three vertices of the previous voxel, that border on the current voxel, to cover the current voxel as well. Those three are the ones that have "z + 1" in them.
Exercises
* Implement this check for the other 5 directions as well.
* How many vertices can potentially be saved using this particular algorithm?
* This algorithm only merges voxel faces along one direction. Can you think of an easy way to merge them in the other direction as well?
* Can we merge with triangles from neightbouring chunks as well?
* Try rendering the chunk with GL_LINES instead of GL_TRIANGLES to see which faces are merged.
- Recent stats
< OpenGL Programming
# OpenGL Programming/Glossary

* FBO: FrameBuffer Object: off-screen drawing - w:Framebuffer Object
* index: position in an array, used in glDrawElements to reference vertices in an arbitrary order (plural: indices)
* indices: plural of index
* VBO: Vertex Buffer Object - w:Vertex Buffer Object
* vertex: a point in 3D space (plural: vertices) - w:Vertex (geometry)
* vertices: plural of vertex
- Recent stats
< OpenGL Programming
# Physics Using Geometric Algebra
## Introduction

* Mathematical Introduction
* Basic Geometric Algebra

## Relativistic Classical Mechanics

* Spacetime position
* Lorentz transformations
* The electromagnetic field
* The Classical Spinor
* References

## Relativistic Quantum Mechanics

* The Dirac equation
* Relation with the standard representation
* Non-relativistic limit
# Physics Textbook/Summary
### FORCES

>>Newtons Second Law of Motion<< Equation : [F=ma], where 'a' sometimes can be used as 'G' which is equal to [9.8 m.s¯ ²]
# Physics Textbook/The Law of Inertia

Bodies at rest will remain at rest and bodies in motion will continue to move with a constant speed along straight path unless they are acted upon by a net force.
# Physics Using Geometric Algebra/Relativistic Classical Mechanics/References
## Some sources of other information

The web site of William E. Baylis has some extended information on the notation used.
In particular, Relativity in Introductory Physics explains in more detail some of the notation used in this wikibook.
# Pinyin/Injured by knife

See also
# Pinyin/Injured seriously

See also
# Optimizing C++/General optimization techniques

In this section we present some common techniques for algorithmic optimization. These techniques should mostly be independent of the programming language, software or hardware platform. When optimizing, always start by considering different algorithms before resorting to lower-level optimizations in order to retain generality, maintainability and portability in your code.
Some of the proposed techniques will have an implementation in C++.
* Input/Output
* Memoization
* Sorting
* Other techniques
# Optimizing C++/Guidelines for editors
## Conventions

This is the local manual of style (WB:LMOS) for the Optimizing C++ Wikibook.
These conventions are not part of the book, and therefore are to be omitted from the PDF version of the book. They are only directives for contributors (aka editors).
This wikibook, after introductory chapters, contains three sets of programming guidelines:
* C++ specific guidelines to be applied at design-time or first-implementation-time.
* Language independent guidelines to be applied in bottlenecks at optimization-time, with examples in C++.
* C++ specific guidelines to be applied in bottlenecks at optimization-time.
Every guideline has the following format:
* Mnemonic title. It has a Title 3 style.
* Rule, having the following style: "When you are in this situation, do this.". It is in bold type.
* Minimal example of C++ code.
* Rationale.
The C++ programming style is loosely that used in the books written by Bjarne Stroustrup.
There are no comparisons with other programming languages, except the C language.
Every guideline specifies exactly when it is to be applied, and what the programmer has to do to apply it.
Little reference is done to compiler optimization technology.
Only the most general and useful algorithms are mentioned.
Little reference is done to specific computer architectures, compilers, and operating systems.
The following terms are used:
* Member function, instead of method.
* Member variable, instead of instance variable.
* Function, instead of routine or procedure. The word routine is used only for machine language code.
* Argument, instead of parameter, for functions declarations, definitions or calls.
* Parameter, instead of argument, for templates definitions or instantiations.
# Optimizing C++/Further reading

* Calling conventions for different C++ compilers and operating systems
* Optimizing software in C++: An optimization guide for Windows, Linux and Mac platforms
* "Technical Report on C++ Performance" by Dave Abrahams et. al. 2003
* "Code optimization tips for 8-bit microcontrollers" by Steve Kolokowsky 2009
* "Getting the Least Out of Your C Compiler" by Jakob Engblom 2001 lists "some of the more common mistakes and how to avoid them, ... An important conclusion is that code that is easy for a human to understand is usually also compiler friendly, contrary to hacker tradition."
* Efficient C++: Performance Programming Techniques; Dov Bulka, David Mayhew
* Inside the C++ Object Model; Stanley B. Lippman
* What Every Programmer Should Know About Memory; Drepper, Ulrich
* The Software Optimization Cookbook; Richard Gerber, et al.
* Optimized C++ Proven Techniques for Heightened Performance; Kurt Guntheroth
# Optimizing C++/Introduction

One of the main reason for preferring C++ over simpler, higher-level programming languages is that C++ allows the development of complex software in a way that makes more efficient use of hardware resources than when using these other languages. The language does not guarantee efficient code automatically, but provides a toolchest that aids programmers in the pursuit of efficiency. Sloppy C++ code may be no more efficient than higher-level implementations of the same algorithms, but a good C++ programmer with knowledge of the language can write software that is efficient from the first cut and then optimize the code further. This book provides techniques for writing efficient code and for optimizing existing software.
Often, there is no single solution to a programming problem that is optimal for all cases. Thus, optimization generally does not mean writing optimally performing software; rather, it means incrementally changing (refactoring) software to increase its performance, bringing it closer to the optimum.
Such optimization requires that the software source is written in a sufficiently modular way that performance critical parts can be isolated. With suitably written code, it then requires the use of tools, libraries, knowledge and time to change those parts in a way that increases the overall execution speed of the software.
Nowadays, many optimizations are already performed by compilers and are no longer the programmer's burden. This book discusses higher-level optimizations that present-day compilers are not (yet) able to perform.
This book is aimed at readers already familiar with the C++ language, who want to use it to develop high performance application software or software libraries.
Almost all of the optimization techniques presented are platform independent and, therefore, there will be few references to specific operating systems, processor architectures or compilers. However, some of the presented techniques may be ineffective or inapplicable in some combinations of operating system/processor/compiler.
# Pinyin/Suspect

See also
# Pinyin/Syllable

See also
A syllable is a single unit of sound made in the pronunciation of a word.
yinjier shih gouhcherng ciryuu fayin d durlih danweih.
# Pinyin/Symbol

See also
A symbol is a picture or shape used to represent something.
furhaoh shih daihbiaao moouwuh d turhuah huoh turxirng.
# Pinyin/Synthesis

Search Pinyin synthesis
# Pinyin/Sustain

See also
# Pinyin/Sweet

See also
# Pinyin/Syntax

See also
Syntax is the rules of structure of sentences. This term also refers to the study of such principles. The goal of many syntacticians is to find out the common syntactic rules of all languages.
Jùfǎ shì jùzi jiégòu de guīzé. Cǐ shùyǔ yě zhǐ cǐlèi yuánlǐ de yánjiū. Xǔduō jùfǎxuéjiā de mùbiāo shì zhǎochū suǒyǒu yǔyán gòngtóng de jùfǎ guīzé.
# Pinyin/Suspected

See also
# Pinyin/Symptom

Search symptom
A symptom is a sign of a illness.
zhehngzhuahng shih jirbihng d zhengzhaoh.
# Pinyin/Syndrome

See also
# Organelles/Nucleus
## Nucleus

In case you forgot, cells have their genetic instructions stored in DNA molecules. These molecules can be either 'covered' or not. This cover is called nucleus. Procaryotes don't have a nucleus, whereas, eucaryotes have one.
There are 2 concentric layers covering nucleus, which is the nuclear envelope. In interphase, the nucleus does not show its chromosomes (which are coined DNA anyway). When the cell is about to divide, its nucleus condenses and chromosomes gradually appear as 2 bunch of wires, each one move to one side of the cell.
# Organic Business Guide
## Contents

Download The Organic Business Guide as FREE PDF . French and Spanish versions are available from the same site. Any reproduction in full or part of this publication is encouraged, but must identify the title of the publication and IFOAM as the publisher.
Profit from the possibility to enhance the guide by contributing to this Wikibook!
* About this book
* Acknowledgements
* Foreword
* Abbreviations
* Definitions
* Introduction to the guide
* Organic production and Fair Trade
* Starting from the market
* Developing organic value chains
* Designing the organic production system
* Planning and managing your business
* Organising producers for the market
* Certification and internal control systems
* From field to market
* Marketing
* Moving up
* Roles for facilitators, governments and donors
* Annexes
* Tools
# Organic Business Guide/Abbreviations
## Abbreviations

* AELBI Agro Eco - Louis Bolk Institute
* BDS Business Development Services
* CAD Cash Against Documents
* CB Certification body
* CIF Carrier, insurance, freight
* CFR Cost and Freight
* FLO Fair trade Labelling Organisations
* FOB Free on board
* GMO Genetically modified organism
* GPS Geographic Positioning System
* ha Hectare
* HACCP Hazard Analysis and Critical Control Point
* ICS Internal Control System
* IFOAM International Federation of Organic Agricultural Movements
* ISO International Organisation for Standardisation
* JAS Japanese Agricultural Standards
* NGO Non Governmental Organisation
* NOP National Organic Programme (US)
* OFT Organic & Fair trade
* PO Producer organisation
* PGS Participatory Guarantee System
* SPS Sanitary and Phytosanitary
* SWOT Method to analyze Strengths, Weaknesses, Opportunities and Threats
* USP Unique Selling Point
# Organ/Types of Organs

There are several different types of organs.
A pipe organ forces air through many large and small pipes, each of which produces a unique pitch and timbre. This is the largest, oldest, most majestic, most expensive, most complicated, and arguably most expressive type of organ.
A reed organ may be the size of an upright piano and forces air through metal reeds, much like a harmonica. It sounds similar to an oboe or an accordion.
A Hammond organ has rotating tone wheels which produce various overtones which when mixed together in various levels produce a wide variety of sounds which are projected through rotating Leslie speakers. It has a very pure tone like a flute, but when distortion is applied may sound very "crunchy" like an electric guitar.
A digital organ is a sampler; it stores the sounds of many pipe organs and faithfully reproduces them with speakers on an appropriately grand machine with many registers and stops.
# Organ/Introduction

The organ, commonly described as being the king of musical instruments, has been around for hundreds of years. It makes sounds via air that is let through certain pipes when keys are employed on the keyboards of the organ (called manuals). Until the invention of telephone operator switchboards in the early 20th century, it was the most mechanically complicated device created by humans.

## Why play the organ?

The organ is a very satisfying instrument to play. You have at your disposal essentially an entire orchestra of different-sounding pipes and even, in some theatre organs, percussion. It has the largest range of any musical instrument and the most sound variety.
There is always a demand for organists in churches, either for solos, to accompany a choir, or provide background music for a Mass.
Playing the organ helps improve your posture and helps develop strength, agility, and coordination because you have to use all your extremities, sometimes simultaneously.
While piano also enables a performer to play notes and chords with both hands, an organ also has a pedalboard, so the feet can play notes as well.
# Organ/Operating the Console

The console is the part of the organ where the performer sits. It includes the manuals, pedals, switches, and various other devices. This is the "cockpit" via which the organ is played.
Besides the manuals, there are many other visible items at the console. The most important are the stops or registers, which allow air to flow to certain pipes to make different sounds. In old organs, the stops are generally knobs that you pull out to activate; on newer models, and especially electrically-operated ones, they come in the form of on-off switches.
The number of stops varies considerably from organ to organ. A small practice organ with two manuals may have as few as 15-20 stops, while a massive four-manual cathedral organ can have well over a hundred.
Because there are so many switches on the average organ, it can be very time-consuming and inconvenient if you have to change stops while in the middle of a piece. For this reason, many instruments have pistons, or buttons on the side of a manual that can be pre-set to immediately turn on a specified combinations of pipes when pressed, thereby avoiding the hassle of having to individually change each pipe stop by hand. Sometimes these pistons are located near the pedals as well for the feet to operate, called toe pistons.
Old organs usually don't have pistons, meaning that all stops have to be changed manually. This usually means that you will need a registrant, a helper that stands around the organist pulling stops when needed so the organist himself doesn't need to take his hands off the keys and interrupt the music.
On many new organs, there is often a "tutti" or "sforzando" button that turns on all of the pipes for the loudest, fullest organ sound (possibly barring any percussion). There is also often an "cancel" button that deactivates all of the stops.
# Organ/Playing the Manuals

If you're already familiar with how to play keyboards, then playing on the manuals should pose no difficulty for you. Bear in mind though, that dynamics are not controlled by how hard you strike they keys (like on a piano). Organ technique and fingerings also vary differently from other, stringed keyboard instruments because there is no "decay" after you press and hold a note. This allows for more finger substitution.
Depending on what type of organ you have available, the action may be electrical or manual (called tracker action). If it's the former, then the keys should be fairly easy to press, but if it's the former, depending on construction and age, the keyboard may have a very heavy, deep action and you may have to adjust your playing style accordingly to accommodate for it.
Almost all organs have two manuals or more. As said previously, they operate different pipes in the organ, allowing you to have several different sounds available simply by changing manuals while playing, without having to change stops. You might want to practise by playing a chord on one manual and then moving it to another manual and playing the same notes. Try to do it quickly yet smoothly, so there is a minimal break where you lift your hand.
# Organ/Playing the Pedals

The pedals are played with your feet and are on the floor of the console. If you look carefully, they are arranged in the pattern of a regular keyboard, only much larger so that the feet can operate them. The range of the pedal keyboard on most modern instruments is from the contra-C to an F or G two octaves above (although older, Baroque instruments may go up to only a C for exactly two octaves). Hammond organs such as the B-3 have a two octave pedalboard. Smaller Hammond spinets may only have a one octave pedalboard.
The pedals are primarily used to play the lowest pitched bass line of a score, and usually go down lower in pitch than the manuals by an octave or more. (On many organs, the pedals can also play up as high as the manuals with the aid of couplers and high registers, but such usage is infrequent.)
Most modern organists play the pedals with both the tips (toes) and heels of their feet, sometimes simultaneously if the music requires it.
Because you don't have the same mobility in your feet as in your hands, the pedal part is usually not called upon to play fast, complex music with lots of skips.
You might want to invest in a pair of specifically designed organ shoes to assist with your playing the pedals. Organ shoes are generally black, leather shoes with a narrow heel and pointed toes to make hitting a pedal accurately easier. Most regular street shoes have wide heels, meaning that it's easy to slip and accidentally hit two notes at once with your foot.
If you can't get organ shoes for some reason, you could alternatively try playing in your socks, although this can be hard on the balls of your feet (and there is always the uncomfortable faux pas of having to remove your shoes in front of an audience if performing).