Music and mathematics

From Wikipedia, the free encyclopedia

https://en.wikipedia.org/wiki/Music_and_mathematics 

A spectrogram of a violin waveform, with linear frequency on the vertical axis and time on the horizontal axis. The bright lines show how the spectral components change over time. The intensity colouring is logarithmic (black is −120 dBFS).

Music theory analyzes the pitch, timing, and structure of music. It uses mathematics to study elements of music such as tempo, chord progression, form, and meter. The attempt to structure and communicate new ways of composing and hearing music has led to musical applications of set theory, abstract algebra and number theory.

While music theory has no axiomatic foundation in modern mathematics, the basis of musical sound can be described mathematically (using acoustics) and exhibits "a remarkable array of number properties".

History

Though ancient Chinese, Indians, Egyptians and Mesopotamians are known to have studied the mathematical principles of sound, the Pythagoreans (in particular Philolaus and Archytas) of ancient Greece were the first researchers known to have investigated the expression of musical scales in terms of numerical ratios, particularly the ratios of small integers. Their central doctrine was that "all nature consists of harmony arising out of numbers".

From the time of Plato, harmony was considered a fundamental branch of physics, now known as musical acoustics. Early Indian and Chinese theorists show similar approaches: all sought to show that the mathematical laws of harmonics and rhythms were fundamental not only to our understanding of the world but to human well-being. Confucius, like Pythagoras, regarded the small numbers 1,2,3,4 as the source of all perfection.

Time, rhythm, and meter

Without the boundaries of rhythmic structure – a fundamental equal and regular arrangement of pulse repetition, accent, phrase and duration – music would not be possible. Modern musical use of terms like meter and measure also reflects the historical importance of music, along with astronomy, in the development of counting, arithmetic and the exact measurement of time and periodicity that is fundamental to physics.

The elements of musical form often build strict proportions or hypermetric structures (powers of the numbers 2 and 3).

Musical form

Main article: Musical form

Musical form is the plan by which a short piece of music is extended. The term "plan" is also used in architecture, to which musical form is often compared. Like the architect, the composer must take into account the function for which the work is intended and the means available, practicing economy and making use of repetition and order. The common types of form known as binary and ternary ("twofold" and "threefold") once again demonstrate the importance of small integral values to the intelligibility and appeal of music.

Frequency and harmony

Chladni figures produced by sound vibrations in fine powder on a square plate. (Ernst Chladni, Acoustics, 1802)

A musical scale is a discrete set of pitches used in making or describing music. The most important scale in the Western tradition is the diatonic scale but many others have been used and proposed in various historical eras and parts of the world. Each pitch corresponds to a particular frequency, expressed in hertz (Hz), sometimes referred to as cycles per second (c.p.s.). A scale has an interval of repetition, normally the octave. The octave of any pitch refers to a frequency exactly twice that of the given pitch.

Succeeding superoctaves are pitches found at frequencies four, eight, sixteen times, and so on, of the fundamental frequency. Pitches at frequencies of half, a quarter, an eighth and so on of the fundamental are called suboctaves. There is no case in musical harmony where, if a given pitch be considered accordant, that its octaves are considered otherwise. Therefore, any note and its octaves will generally be found similarly named in musical systems (e.g. all will be called doh or A or Sa, as the case may be).

When expressed as a frequency bandwidth an octave A₂–A₃ spans from 110 Hz to 220 Hz (span=110 Hz). The next octave will span from 220 Hz to 440 Hz (span=220 Hz). The third octave spans from 440 Hz to 880 Hz (span=440 Hz) and so on. Each successive octave spans twice the frequency range of the previous octave.

The exponential nature of octaves when measured on a linear frequency scale.

This diagram presents octaves as they appear in the sense of musical intervals, equally spaced.

Because we are often interested in the relations or ratios between the pitches (known as intervals) rather than the precise pitches themselves in describing a scale, it is usual to refer to all the scale pitches in terms of their ratio from a particular pitch, which is given the value of one (often written 1/1), generally a note which functions as the tonic of the scale. For interval size comparison, cents are often used.

Oscillogram of middle C (262 Hz). (Scale: 1 square is equal to 1 millisecond)

C5, an octave above middle C. The frequency is twice that of middle C (523 Hz).

C3, an octave below middle C. The frequency is half that of middle C (131 Hz).

Common term	Example name	Hz	Multiple of fundamental	Ratio of within octave	Cents within octave
Fundamental	A2	110	${\displaystyle 1x}$	${\displaystyle 1/1=1x}$	0
Octave	A3	220	${\displaystyle 2x}$	${\displaystyle 2/1=2x}$	1200
				${\displaystyle 2/2=1x}$	0
Perfect Fifth	E4	330	${\displaystyle 3x}$	${\displaystyle 3/2=1.5x}$	702
Octave	A4	440	${\displaystyle 4x}$	${\displaystyle 4/2=2x}$	1200
				${\displaystyle 4/4=1x}$	0
Major Third	C♯5	550	${\displaystyle 5x}$	${\displaystyle 5/4=1.25x}$	386
Perfect Fifth	E5	660	${\displaystyle 6x}$	${\displaystyle 6/4=1.5x}$	702
Harmonic seventh	G5	770	${\displaystyle 7x}$	${\displaystyle 7/4=1.75x}$	969
Octave	A5	880	${\displaystyle 8x}$	${\displaystyle 8/4=2x}$	1200
				${\displaystyle 8/8=1x}$	0

Tuning systems

Main articles: Musical tuning and Musical temperament

There are two main families of tuning systems: equal temperament and just tuning. Equal temperament scales are built by dividing an octave into intervals which are equal on a logarithmic scale, which results in perfectly evenly divided scales, but with ratios of frequencies which are irrational numbers. Just scales are built by multiplying frequencies by rational numbers, which results in simple ratios between frequencies, but with scale divisions that are uneven.

One major difference between equal temperament tunings and just tunings is differences in acoustical beat when two notes are sounded together, which affects the subjective experience of consonance and dissonance. Both of these systems, and the vast majority of music in general, have scales that repeat on the interval of every octave, which is defined as frequency ratio of 2:1. In other words, every time the frequency is doubled, the given scale repeats.

Below are Ogg Vorbis files demonstrating the difference between just intonation and equal temperament. You might need to play the samples several times before you can detect the difference.

• Two sine waves played consecutively – this sample has half-step at 550 Hz (C♯ in the just intonation scale), followed by a half-step at 554.37 Hz (C♯ in the equal temperament scale).
• Same two notes, set against an A440 pedal – this sample consists of a "dyad". The lower note is a constant A (440 Hz in either scale), the upper note is a C♯ in the equal-tempered scale for the first 1", and a C♯ in the just intonation scale for the last 1". Phase differences make it easier to detect the transition than in the previous sample.

Just tunings

The first 16 harmonics, their names and frequencies, showing the exponential nature of the octave and the simple fractional nature of non-octave harmonics.

The first 16 harmonics, with frequencies and log frequencies.

5-limit tuning, the most common form of just intonation, is a system of tuning using tones that are regular number harmonics of a single fundamental frequency. This was one of the scales Johannes Kepler presented in his Harmonices Mundi (1619) in connection with planetary motion. The same scale was given in transposed form by Scottish mathematician and musical theorist, Alexander Malcolm, in 1721 in his 'Treatise of Musick: Speculative, Practical and Historical', and by theorist Jose Wuerschmidt in the 20th century. A form of it is used in the music of northern India.

American composer Terry Riley also made use of the inverted form of it in his "Harp of New Albion". Just intonation gives superior results when there is little or no chord progression: voices and other instruments gravitate to just intonation whenever possible. However, it gives two different whole tone intervals (9:8 and 10:9) because a fixed tuned instrument, such as a piano, cannot change key. To calculate the frequency of a note in a scale given in terms of ratios, the frequency ratio is multiplied by the tonic frequency. For instance, with a tonic of A4 (A natural above middle C), the frequency is 440 Hz, and a justly tuned fifth above it (E5) is simply 440×(3:2) = 660 Hz.

Semitone	Ratio	Interval	Natural	Half Step
0	1:1	unison	480	0
1	16:15	semitone	512	16:15
2	9:8	major second	540	135:128
3	6:5	minor third	576	16:15
4	5:4	major third	600	25:24
5	4:3	perfect fourth	640	16:15
6	45:32	diatonic tritone	675	135:128
7	3:2	perfect fifth	720	16:15
8	8:5	minor sixth	768	16:15
9	5:3	major sixth	800	25:24
10	9:5	minor seventh	864	27:25
11	15:8	major seventh	900	25:24
12	2:1	octave	960	16:15

Pythagorean tuning is tuning based only on the perfect consonances, the (perfect) octave, perfect fifth, and perfect fourth. Thus the major third is considered not a third but a ditone, literally "two tones", and is (9:8)² = 81:64, rather than the independent and harmonic just 5:4 = 80:64 directly below. A whole tone is a secondary interval, being derived from two perfect fifths minus an octave, (3:2)²/2 = 9:8.

The just major third, 5:4 and minor third, 6:5, are a syntonic comma, 81:80, apart from their Pythagorean equivalents 81:64 and 32:27 respectively. According to Carl Dahlhaus (1990, p. 187), "the dependent third conforms to the Pythagorean, the independent third to the harmonic tuning of intervals."

Western common practice music usually cannot be played in just intonation but requires a systematically tempered scale. The tempering can involve either the irregularities of well temperament or be constructed as a regular temperament, either some form of equal temperament or some other regular meantone, but in all cases will involve the fundamental features of meantone temperament. For example, the root of chord ii, if tuned to a fifth above the dominant, would be a major whole tone (9:8) above the tonic. If tuned a just minor third (6:5) below a just subdominant degree of 4:3, however, the interval from the tonic would equal a minor whole tone (10:9). Meantone temperament reduces the difference between 9:8 and 10:9. Their ratio, (9:8)/(10:9) = 81:80, is treated as a unison. The interval 81:80, called the syntonic comma or comma of Didymus, is the key comma of meantone temperament.

Equal temperament tunings

In equal temperament, the octave is divided into equal parts on the logarithmic scale. While it is possible to construct equal temperament scale with any number of notes (for example, the 24-tone Arab tone system), the most common number is 12, which makes up the equal-temperament chromatic scale. In western music, a division into twelve intervals is commonly assumed unless it is specified otherwise.

For the chromatic scale, the octave is divided into twelve equal parts, each semitone (half-step) is an interval of the twelfth root of two so that twelve of these equal half steps add up to exactly an octave. With fretted instruments it is very useful to use equal temperament so that the frets align evenly across the strings. In the European music tradition, equal temperament was used for lute and guitar music far earlier than for other instruments, such as musical keyboards. Because of this historical force, twelve-tone equal temperament is now the dominant intonation system in the Western, and much of the non-Western, world.

Equally tempered scales have been used and instruments built using various other numbers of equal intervals. The 19 equal temperament, first proposed and used by Guillaume Costeley in the 16th century, uses 19 equally spaced tones, offering better major thirds and far better minor thirds than normal 12-semitone equal temperament at the cost of a flatter fifth. The overall effect is one of greater consonance. Twenty-four equal temperament, with twenty-four equally spaced tones, is widespread in the pedagogy and notation of Arabic music. However, in theory and practice, the intonation of Arabic music conforms to rational ratios, as opposed to the irrational ratios of equally tempered systems.

While any analog to the equally tempered quarter tone is entirely absent from Arabic intonation systems, analogs to a three-quarter tone, or neutral second, frequently occur. These neutral seconds, however, vary slightly in their ratios dependent on maqam, as well as geography. Indeed, Arabic music historian Habib Hassan Touma has written that "the breadth of deviation of this musical step is a crucial ingredient in the peculiar flavor of Arabian music. To temper the scale by dividing the octave into twenty-four quarter-tones of equal size would be to surrender one of the most characteristic elements of this musical culture."

53 equal temperament arises from the near equality of 53 perfect fifths with 31 octaves, and was noted by Jing Fang and Nicholas Mercator.

Connections to mathematics

Set theory

Main article: Set theory (music)

Musical set theory uses the language of mathematical set theory in an elementary way to organize musical objects and describe their relationships. To analyze the structure of a piece of (typically atonal) music using musical set theory, one usually starts with a set of tones, which could form motives or chords. By applying simple operations such as transposition and inversion, one can discover deep structures in the music. Operations such as transposition and inversion are called isometries because they preserve the intervals between tones in a set.

Abstract algebra

Main article: Abstract algebra

Expanding on the methods of musical set theory, some theorists have used abstract algebra to analyze music. For example, the pitch classes in an equally tempered octave form an abelian group with 12 elements. It is possible to describe just intonation in terms of a free abelian group.

Transformational theory is a branch of music theory developed by David Lewin. The theory allows for great generality because it emphasizes transformations between musical objects, rather than the musical objects themselves.

Theorists have also proposed musical applications of more sophisticated algebraic concepts. The theory of regular temperaments has been extensively developed with a wide range of sophisticated mathematics, for example by associating each regular temperament with a rational point on a Grassmannian.

The chromatic scale has a free and transitive action of the cyclic group ${\displaystyle \mathbb{Z}/12\mathbb{Z}}$, with the action being defined via transposition of notes. So the chromatic scale can be thought of as a torsor for the group.

Numbers and series

Some composers have incorporated the golden ratio and Fibonacci numbers into their work.

Category theory

Main article: Category theory

The mathematician and musicologist Guerino Mazzola has used category theory (topos theory) for a basis of music theory, which includes using topology as a basis for a theory of rhythm and motives, and differential geometry as a basis for a theory of musical phrasing, tempo, and intonation.

Musicians who were or are also mathematicians

• Albert Einstein - Accomplished pianist and violinist.
• Art Garfunkel (Simon & Garfunkel) – Masters in Mathematics Education, Columbia University
• Brian May (Queen) - BSc (Hons) in Mathematics and Physics, PhD in Astrophysics, both from Imperial College London.
• Dan Snaith – PhD Mathematics, Imperial College London
• Delia Derbyshire - BA in mathematics and music from Cambridge.
• Jonny Buckland (Coldplay) - Studied astronomy and mathematics at University College London.
• Kit Armstrong - Degree in music and MSc in mathematics.
• Manjul Bhargava - Plays the tabla, won the Fields Medal in 2014.
• Phil Alvin (The Blasters) – Mathematics, University of California, Los Angeles
• Philip Glass - Studied mathematics and philosophy at the University of Chicago.
• Tom Lehrer - BA mathematics from Harvard University.
• William Herschel - Astronomer and played the oboe, violin, harpsichord and organ. He composed 24 symphonies and many concertos, as well as some church music.
• Jerome Hines - Five articles published in Mathematics Magazine 1951–6.
• Donald Knuth - Knuth is an organist and a composer. In 2016 he completed a musical piece for organ titled Fantasia Apocalyptica. It was premièred in Sweden on January 10, 2018

"Hello, World!" program

From Wikipedia, the free encyclopedia

https://en.wikipedia.org/wiki/%22Hello,_World!%22_program

A "Hello, World!" program is generally a simple computer program which outputs (or displays) to the screen (often the console) a message similar to "Hello, World!" while ignoring any user input. A small piece of code in most general-purpose programming languages, this program is used to illustrate a language's basic syntax. A "Hello, World!" program is often the first written by a student of a new programming language, but such a program can also be used as a sanity check to ensure that the computer software intended to compile or run source code is correctly installed, and that its operator understands how to use it.

History

"Hello, World!" program handwritten in the C language and signed Bria Kergh (Brian Kernighan, 1978)

While small test programs have existed since the development of programmable computers, the tradition of using the phrase "Hello, World!" as a test message was influenced by an example program in the 1978 book The C Programming Language, with likely earlier use in BCPL. The example program from the book prints "hello, world", and was inherited from a 1974 Bell Laboratories internal memorandum by Brian Kernighan, Programming in C: A Tutorial:

main( ) {
        printf("hello, world");
}

In the above example, the main( ) function defines where the program should start executing. The function body consists of a single statement, a call to the printf() function, which stands for "print formatted"; it outputs to the console whatever is passed to it as the parameter, in this case the string "hello, world".

The C-language version was preceded by Kernighan's own 1972 A Tutorial Introduction to the Language B, where the first known version of the program is found in an example used to illustrate external variables:

main( ) {
    extern a, b, c;
    putchar(a); putchar(b); putchar(c); putchar('!*n');
}
 
a 'hell';
b 'o, w';
c 'orld';

The program above prints hello, world! on the terminal, including a newline character. The phrase is divided into multiple variables because in B a character constant is limited to four ASCII characters. The previous example in the tutorial printed hi! on the terminal, and the phrase hello, world! was introduced as a slightly longer greeting that required several character constants for its expression.

The Jargon File reports that "hello, world" instead originated in 1967 with the language BCPL. Outside computing, use of the exact phrase began over a decade prior; it was the catchphrase of New York radio disc jockey William B. Williams beginning in the 1950s.

Variations

A "Hello, World!" program running on Sony's PlayStation Portable as a proof of concept

"Hello, World!" programs vary in complexity between different languages. In some languages, particularly scripting languages, the "Hello, World!" program can be written as a single statement, while in others (particularly many low-level languages) there can be many more statements required. For example, in Python, to print the string Hello, World! followed by a newline, one only needs to write print("Hello, World!"). In contrast, the equivalent code in C++ requires the import of the input/output software library, the manual declaration of an entry point, and the explicit instruction that the output string should be sent to the standard output stream.

CNC machining test in Perspex

The phrase "Hello, World!" has seen various deviations in casing and punctuation, such as the capitalization of the leading H and W, and the presence of the comma or exclamation mark. Some devices limit the format to specific variations, such as all-capitalized versions on systems that support only capital letters, while some esoteric programming languages may have to print a slightly modified string. For example, the first non-trivial Malbolge program printed "HEllO WORld", this having been determined to be good enough. Other human languages have been used as the output; for example, a tutorial for the Go programming language outputted both English and Chinese or Japanese characters, demonstrating the programming language's built-in Unicode support. Another notable example is the Rust programming language, whose management system automatically inserts a "Hello, World" program when creating new projects.

A "Hello, World!" message being displayed through long-exposure light painting with a moving strip of LEDs

Some languages change the functionality of the "Hello, World!" program while maintaining the spirit of demonstrating a simple example. Functional programming languages, such as Lisp, ML, and Haskell, tend to substitute a factorial program for "Hello, World!", as functional programming emphasizes recursive techniques, whereas the original examples emphasize I/O, which violates the spirit of pure functional programming by producing side effects. Languages otherwise capable of printing "Hello, World!" (Assembly, C, VHDL) may also be used in embedded systems, where text output is either difficult (requiring additional components or communication with another computer) or nonexistent. For devices such as microcontrollers, field-programmable gate arrays, and CPLDs, "Hello, World!" may thus be substituted with a blinking LED, which demonstrates timing and interaction between components.

The Debian and Ubuntu Linux distributions provide the "Hello, World!" program through their software package manager systems, which can be invoked with the command hello. It serves as a sanity check and a simple example of installing a software package. For developers, it provides an example of creating a .deb package, either traditionally or using debhelper, and the version of hello used, GNU Hello, serves as an example of writing a GNU program.

Variations of the "Hello, World!" program that produce a graphical output (as opposed to text output) have also been shown. Sun demonstrated a "Hello, World!" program in Java based on scalable vector graphics, and the XL programming language features a spinning Earth "Hello, World!" using 3D computer graphics. Mark Guzdial and Elliot Soloway have suggested that the "hello, world" test message may be outdated now that graphics and sound can be manipulated as easily as text.

Time to Hello World

"Time to hello world" (TTHW) is the time it takes to author a "Hello, World!" program in a given programming language. This is one measure of a programming language's ease of use; since the program is meant as an introduction for people unfamiliar with the language, a more complex "Hello, World!" program may indicate that the programming language is less approachable. The concept has been extended beyond programming languages to APIs, as a measure of how simple it is for a new developer to get a basic example working; a shorter time indicates an easier API for developers to adopt.

Hardware virtualization

From Wikipedia, the free encyclopedia

https://en.wikipedia.org/wiki/Hardware_virtualization 

Hardware virtualization is the virtualization of computers as complete hardware platforms, certain logical abstractions of their componentry, or only the functionality required to run various operating systems. Virtualization hides the physical characteristics of a computing platform from the users, presenting instead an abstract computing platform. At its origins, the software that controlled virtualization was called a "control program", but the terms "hypervisor" or "virtual machine monitor" became preferred over time.

Concept

The term "virtualization" was coined in the 1960s to refer to a virtual machine (sometimes called "pseudo machine"), a term which itself dates from the experimental IBM M44/44X system. The creation and management of virtual machines has also been called "platform virtualization", or "server virtualization", more recently.

Platform virtualization is performed on a given hardware platform by host software (a control program), which creates a simulated computer environment, a virtual machine (VM), for its guest software. The guest software is not limited to user applications; many hosts allow the execution of complete operating systems. The guest software executes as if it were running directly on the physical hardware, with several notable caveats. Access to physical system resources (such as the network access, display, keyboard, and disk storage) is generally managed at a more restrictive level than the host processor and system-memory. Guests are often restricted from accessing specific peripheral devices, or may be limited to a subset of the device's native capabilities, depending on the hardware access policy implemented by the virtualization host.

Virtualization often exacts performance penalties, both in resources required to run the hypervisor, and as well as in reduced performance on the virtual machine compared to running native on the physical machine.

Reasons for virtualization

• In the case of server consolidation, many small physical servers can be replaced by one larger physical server to decrease the need for more (costly) hardware resources such as CPUs, and hard drives. Although hardware is consolidated in virtual environments, typically OSs are not. Instead, each OS running on a physical server is converted to a distinct OS running inside a virtual machine. Thereby, the large server can "host" many such "guest" virtual machines. This is known as Physical-to-Virtual (P2V) transformation.
• In addition to reducing equipment and labor costs associated with equipment maintenance, consolidating servers can also have the added benefit of reducing energy consumption and the global footprint in environmental-ecological sectors of technology. For example, a typical server runs at 425 W and VMware estimates a hardware reduction ratio of up to 15:1.
• A virtual machine (VM) can be more easily controlled and inspected from a remote site than a physical machine, and the configuration of a VM is more flexible. This is very useful in kernel development and for teaching operating system courses, including running legacy operating systems that do not support modern hardware.
• A new virtual machine can be provisioned as required without the need for an up-front hardware purchase.
• A virtual machine can easily be relocated from one physical machine to another as needed. For example, a salesperson going to a customer can copy a virtual machine with the demonstration software to their laptop, without the need to transport the physical computer. Likewise, an error inside a virtual machine does not harm the host system, so there is no risk of the OS crashing on the laptop.
• Because of this ease of relocation, virtual machines can be readily used in disaster recovery scenarios without concerns with impact of refurbished and faulty energy sources.

However, when multiple VMs are concurrently running on the same physical host, each VM may exhibit varying and unstable performance which highly depends on the workload imposed on the system by other VMs. This issue can be addressed by appropriate installation techniques for temporal isolation among virtual machines.

There are several approaches to platform virtualization.

Examples of virtualization use cases:

• Running one or more applications that are not supported by the host OS: A virtual machine running the required guest OS could permit the desired applications to run, without altering the host OS.
• Evaluating an alternate operating system: The new OS could be run within a VM, without altering the host OS.
• Server virtualization: Multiple virtual servers could be run on a single physical server, in order to more fully utilize the hardware resources of the physical server.
• Duplicating specific environments: A virtual machine could, depending on the virtualization software used, be duplicated and installed on multiple hosts, or restored to a previously backed-up system state.
• Creating a protected environment: If a guest OS running on a VM becomes damaged in a way that is not cost-effective to repair, such as may occur when studying malware or installing badly behaved software, the VM may simply be discarded without harm to the host system, and a clean copy used upon rebooting the guest .

Full virtualization

Main article: Full virtualization

Logical diagram of full virtualization.

In full virtualization, the virtual machine simulates enough hardware to allow an unmodified "guest" OS designed for the same instruction set to be run in isolation. This approach was pioneered in 1966 with the IBM CP-40 and CP-67, predecessors of the VM family.

Hardware-assisted virtualization

Main article: Hardware-assisted virtualization

In hardware-assisted virtualization, the hardware provides architectural support that facilitates building a virtual machine monitor and allows guest OSs to be run in isolation. Hardware-assisted virtualization was first introduced on the IBM System/370 in 1972, for use with VM/370, the first virtual machine operating system.

In 2005 and 2006, Intel and AMD developed additional hardware to support virtualization ran on their platforms. Sun Microsystems (now Oracle Corporation) added similar features in their UltraSPARC T-Series processors in 2005.

In 2006, first-generation 32- and 64-bit x86 hardware support was found to rarely offer performance advantages over software virtualization.

Paravirtualization

Main article: Paravirtualization

In paravirtualization, the virtual machine does not necessarily simulate hardware, but instead (or in addition) offers a special API that can only be used by modifying the "guest" OS. For this to be possible, the "guest" OS's source code must be available. If the source code is available, it is sufficient to replace sensitive instructions with calls to VMM APIs (e.g.: "cli" with "vm_handle_cli()"), then re-compile the OS and use the new binaries. This system call to the hypervisor is called a "hypercall" in TRANGO and Xen; it is implemented via a DIAG ("diagnose") hardware instruction in IBM's CMS under VM (which was the origin of the term hypervisor)..

Operating-system-level virtualization

Main article: OS-level virtualization

In operating-system-level virtualization, a physical server is virtualized at the operating system level, enabling multiple isolated and secure virtualized servers to run on a single physical server. The "guest" operating system environments share the same running instance of the operating system as the host system. Thus, the same operating system kernel is also used to implement the "guest" environments, and applications running in a given "guest" environment view it as a stand-alone system.

Hardware virtualization disaster recovery

A disaster recovery (DR) plan is often considered good practice for a hardware virtualization platform. DR of a virtualization environment can ensure high rate of availability during a wide range of situations that disrupt normal business operations. In situations where continued operations of hardware virtualization platforms is important, a disaster recovery plan can ensure hardware performance and maintenance requirements are met. A hardware virtualization disaster recovery plan involves both hardware and software protection by various methods, including those described below.

Tape backup for software data long-term archival needs

This common method can be used to store data offsite, but data recovery can be a difficult and lengthy process. Tape backup data is only as good as the latest copy stored. Tape backup methods will require a backup device and ongoing storage material.

Whole-file and application replication

The implementation of this method will require control software and storage capacity for application and data file storage replication typically on the same site. The data is replicated on a different disk partition or separate disk device and can be a scheduled activity for most servers and is implemented more for database-type applications.

Hardware and software redundancy

This method ensures the highest level of disaster recovery protection for a hardware virtualization solution, by providing duplicate hardware and software replication in two distinct geographic areas.

Abstraction (computer science)

From Wikipedia, the free encyclopedia

https://en.wikipedia.org/wiki/Abstraction_(computer_science)

In software engineering and computer science, abstraction is the process of generalizing concrete details, such as attributes, away from the study of objects and systems to focus attention on details of greater importance. Abstraction is a fundamental concept in computer science and software engineering, especially within the object-oriented programming paradigm. Examples of this include:

• the usage of abstract data types to separate usage from working representations of data within programs;
• the concept of functions or subroutines which represent a specific way of implementing control flow;
• the process of reorganizing common behavior from groups of non-abstract classes into abstract classes using inheritance and sub-classes, as seen in object-oriented programming languages.

Rationale

The essence of abstraction is preserving information that is relevant in a given context, and forgetting information that is irrelevant in that context.

– John V. Guttag

Computing mostly operates independently of the concrete world. The hardware implements a model of computation that is interchangeable with others. The software is structured in architectures to enable humans to create the enormous systems by concentrating on a few issues at a time. These architectures are made of specific choices of abstractions. Greenspun's Tenth Rule is an aphorism on how such an architecture is both inevitable and complex.

A central form of abstraction in computing is language abstraction: new artificial languages are developed to express specific aspects of a system. Modeling languages help in planning. Computer languages can be processed with a computer. An example of this abstraction process is the generational development of programming languages from the machine language to the assembly language and the high-level language. Each stage can be used as a stepping stone for the next stage. The language abstraction continues for example in scripting languages and domain-specific programming languages.

Within a programming language, some features let the programmer create new abstractions. These include subroutines, modules, polymorphism, and software components. Some other abstractions such as software design patterns and architectural styles remain invisible to a translator and operate only in the design of a system.

Some abstractions try to limit the range of concepts a programmer needs to be aware of, by completely hiding the abstractions that they in turn are built on. The software engineer and writer Joel Spolsky has criticised these efforts by claiming that all abstractions are leaky – that they can never completely hide the details below; however, this does not negate the usefulness of abstraction.

Some abstractions are designed to inter-operate with other abstractions – for example, a programming language may contain a foreign function interface for making calls to the lower-level language.

Abstraction features

Programming languages

Main article: Programming language

Different programming languages provide different types of abstraction, depending on the intended applications for the language. For example:

• In object-oriented programming languages such as C++, Object Pascal, or Java, the concept of abstraction has itself become a declarative statement – using the syntax function(parameters) = 0; (in C++) or the keywords abstract and interface (in Java). After such a declaration, it is the responsibility of the programmer to implement a class to instantiate the object of the declaration.
• Functional programming languages commonly exhibit abstractions related to functions, such as lambda abstractions (making a term into a function of some variable) and higher-order functions (parameters are functions).
• Modern members of the Lisp programming language family such as Clojure, Scheme and Common Lisp support macro systems to allow syntactic abstraction. Other programming languages such as Scala also have macros, or very similar metaprogramming features (for example, Haskell has Template Haskell, and OCaml has MetaOCaml). These can allow a programmer to eliminate boilerplate code, abstract away tedious function call sequences, implement new control flow structures, and implement Domain Specific Languages (DSLs), which allow domain-specific concepts to be expressed in concise and elegant ways. All of these, when used correctly, improve both the programmer's efficiency and the clarity of the code by making the intended purpose more explicit. A consequence of syntactic abstraction is also that any Lisp dialect and in fact almost any programming language can, in principle, be implemented in any modern Lisp with significantly reduced (but still non-trivial in most cases) effort when compared to "more traditional" programming languages such as Python, C or Java.

Specification methods

Main article: Formal specification

Analysts have developed various methods to formally specify software systems. Some known methods include:

• Abstract-model based method (VDM, Z);
• Algebraic techniques (Larch, CLEAR, OBJ, ACT ONE, CASL);
• Process-based techniques (LOTOS, SDL, Estelle);
• Trace-based techniques (SPECIAL, TAM);
• Knowledge-based techniques (Refine, Gist).

Specification languages

Main article: Specification language

Specification languages generally rely on abstractions of one kind or another, since specifications are typically defined earlier in a project, (and at a more abstract level) than an eventual implementation. The UML specification language, for example, allows the definition of abstract classes, which in a waterfall project, remain abstract during the architecture and specification phase of the project.

Control abstraction

Main article: Control flow

Programming languages offer control abstraction as one of the main purposes of their use. Computer machines understand operations at the very low level such as moving some bits from one location of the memory to another location and producing the sum of two sequences of bits. Programming languages allow this to be done in the higher level. For example, consider this statement written in a Pascal-like fashion:

a := (1 + 2) * 5

To a human, this seems a fairly simple and obvious calculation ("one plus two is three, times five is fifteen"). However, the low-level steps necessary to carry out this evaluation, and return the value "15", and then assign that value to the variable "a", are actually quite subtle and complex. The values need to be converted to binary representation (often a much more complicated task than one would think) and the calculations decomposed (by the compiler or interpreter) into assembly instructions (again, which are much less intuitive to the programmer: operations such as shifting a binary register left, or adding the binary complement of the contents of one register to another, are simply not how humans think about the abstract arithmetical operations of addition or multiplication). Finally, assigning the resulting value of "15" to the variable labeled "a", so that "a" can be used later, involves additional 'behind-the-scenes' steps of looking up a variable's label and the resultant location in physical or virtual memory, storing the binary representation of "15" to that memory location, etc.

Without control abstraction, a programmer would need to specify all the register/binary-level steps each time they simply wanted to add or multiply a couple of numbers and assign the result to a variable. Such duplication of effort has two serious negative consequences:

1. it forces the programmer to constantly repeat fairly common tasks every time a similar operation is needed
2. it forces the programmer to program for the particular hardware and instruction set

Structured programming

Main article: Structured programming

Structured programming involves the splitting of complex program tasks into smaller pieces with clear flow-control and interfaces between components, with a reduction of the complexity potential for side-effects.

In a simple program, this may aim to ensure that loops have single or obvious exit points and (where possible) to have single exit points from functions and procedures.

In a larger system, it may involve breaking down complex tasks into many different modules. Consider a system which handles payroll on ships and at shore offices:

• The uppermost level may feature a menu of typical end-user operations.
• Within that could be standalone executables or libraries for tasks such as signing on and off employees or printing checks.
• Within each of those standalone components there could be many different source files, each containing the program code to handle a part of the problem, with only selected interfaces available to other parts of the program. A sign on program could have source files for each data entry screen and the database interface (which may itself be a standalone third party library or a statically linked set of library routines).
• Either the database or the payroll application also has to initiate the process of exchanging data with between ship and shore, and that data transfer task will often contain many other components.

These layers produce the effect of isolating the implementation details of one component and its assorted internal methods from the others. Object-oriented programming embraces and extends this concept.

Data abstraction

Main article: Abstract data type

Data abstraction enforces a clear separation between the abstract properties of a data type and the concrete details of its implementation. The abstract properties are those that are visible to client code that makes use of the data type—the interface to the data type—while the concrete implementation is kept entirely private, and indeed can change, for example to incorporate efficiency improvements over time. The idea is that such changes are not supposed to have any impact on client code, since they involve no difference in the abstract behaviour.

For example, one could define an abstract data type called lookup table which uniquely associates keys with values, and in which values may be retrieved by specifying their corresponding keys. Such a lookup table may be implemented in various ways: as a hash table, a binary search tree, or even a simple linear list of (key:value) pairs. As far as client code is concerned, the abstract properties of the type are the same in each case.

Of course, this all relies on getting the details of the interface right in the first place, since any changes there can have major impacts on client code. As one way to look at this: the interface forms a contract on agreed behaviour between the data type and client code; anything not spelled out in the contract is subject to change without notice.

Manual data abstraction

While much of data abstraction occurs through computer science and automation, there are times when this process is done manually and without programming intervention. One way this can be understood is through data abstraction within the process of conducting a systematic review of the literature. In this methodology, data is abstracted by one or several abstractors when conducting a meta-analysis, with errors reduced through dual data abstraction followed by independent checking, known as adjudication.

Abstraction in object oriented programming

Main article: Object (computer science)

In object-oriented programming theory, abstraction involves the facility to define objects that represent abstract "actors" that can perform work, report on and change their state, and "communicate" with other objects in the system. The term encapsulation refers to the hiding of state details, but extending the concept of data type from earlier programming languages to associate behavior most strongly with the data, and standardizing the way that different data types interact, is the beginning of abstraction. When abstraction proceeds into the operations defined, enabling objects of different types to be substituted, it is called polymorphism. When it proceeds in the opposite direction, inside the types or classes, structuring them to simplify a complex set of relationships, it is called delegation or inheritance.

Various object-oriented programming languages offer similar facilities for abstraction, all to support a general strategy of polymorphism in object-oriented programming, which includes the substitution of one type for another in the same or similar role. Although not as generally supported, a configuration or image or package may predetermine a great many of these bindings at compile-time, link-time, or loadtime. This would leave only a minimum of such bindings to change at run-time.

Common Lisp Object System or Self, for example, feature less of a class-instance distinction and more use of delegation for polymorphism. Individual objects and functions are abstracted more flexibly to better fit with a shared functional heritage from Lisp.

C++ exemplifies another extreme: it relies heavily on templates and overloading and other static bindings at compile-time, which in turn has certain flexibility problems.

Although these examples offer alternate strategies for achieving the same abstraction, they do not fundamentally alter the need to support abstract nouns in code – all programming relies on an ability to abstract verbs as functions, nouns as data structures, and either as processes.

Consider for example a sample Java fragment to represent some common farm "animals" to a level of abstraction suitable to model simple aspects of their hunger and feeding. It defines an Animal class to represent both the state of the animal and its functions:

public class Animal extends LivingThing
{
     private Location loc;
     private double energyReserves;

     public boolean isHungry() {
         return energyReserves < 2.5;
     }
     public void eat(Food food) {
         // Consume food
         energyReserves += food.getCalories();
     }
     public void moveTo(Location location) {
         // Move to new location
         this.loc = location;
     }
}

With the above definition, one could create objects of type Animal and call their methods like this:

thePig = new Animal();
theCow = new Animal();
if (thePig.isHungry()) {
    thePig.eat(tableScraps);
}
if (theCow.isHungry()) {
    theCow.eat(grass);
}
theCow.moveTo(theBarn);

In the above example, the class Animal is an abstraction used in place of an actual animal, LivingThing is a further abstraction (in this case a generalisation) of Animal.

If one requires a more differentiated hierarchy of animals – to differentiate, say, those who provide milk from those who provide nothing except meat at the end of their lives – that is an intermediary level of abstraction, probably DairyAnimal (cows, goats) who would eat foods suitable to giving good milk, and MeatAnimal (pigs, steers) who would eat foods to give the best meat-quality.

Such an abstraction could remove the need for the application coder to specify the type of food, so they could concentrate instead on the feeding schedule. The two classes could be related using inheritance or stand alone, and the programmer could define varying degrees of polymorphism between the two types. These facilities tend to vary drastically between languages, but in general each can achieve anything that is possible with any of the others. A great many operation overloads, data type by data type, can have the same effect at compile-time as any degree of inheritance or other means to achieve polymorphism. The class notation is simply a coder's convenience.

Object-oriented design

Main article: Object-oriented design

Decisions regarding what to abstract and what to keep under the control of the coder become the major concern of object-oriented design and domain analysis—actually determining the relevant relationships in the real world is the concern of object-oriented analysis or legacy analysis.

In general, to determine appropriate abstraction, one must make many small decisions about scope (domain analysis), determine what other systems one must cooperate with (legacy analysis), then perform a detailed object-oriented analysis which is expressed within project time and budget constraints as an object-oriented design. In our simple example, the domain is the barnyard, the live pigs and cows and their eating habits are the legacy constraints, the detailed analysis is that coders must have the flexibility to feed the animals what is available and thus there is no reason to code the type of food into the class itself, and the design is a single simple Animal class of which pigs and cows are instances with the same functions. A decision to differentiate DairyAnimal would change the detailed analysis but the domain and legacy analysis would be unchanged—thus it is entirely under the control of the programmer, and it is called an abstraction in object-oriented programming as distinct from abstraction in domain or legacy analysis.

Considerations

When discussing formal semantics of programming languages, formal methods or abstract interpretation, abstraction refers to the act of considering a less detailed, but safe, definition of the observed program behaviors. For instance, one may observe only the final result of program executions instead of considering all the intermediate steps of executions. Abstraction is defined to a concrete (more precise) model of execution.

Abstraction may be exact or faithful with respect to a property if one can answer a question about the property equally well on the concrete or abstract model. For instance, if one wishes to know what the result of the evaluation of a mathematical expression involving only integers +, -, ×, is worth modulo n, then one needs only perform all operations modulo n (a familiar form of this abstraction is casting out nines).

Abstractions, however, though not necessarily exact, should be sound. That is, it should be possible to get sound answers from them—even though the abstraction may simply yield a result of undecidability. For instance, students in a class may be abstracted by their minimal and maximal ages; if one asks whether a certain person belongs to that class, one may simply compare that person's age with the minimal and maximal ages; if his age lies outside the range, one may safely answer that the person does not belong to the class; if it does not, one may only answer "I don't know".

The level of abstraction included in a programming language can influence its overall usability. The Cognitive dimensions framework includes the concept of abstraction gradient in a formalism. This framework allows the designer of a programming language to study the trade-offs between abstraction and other characteristics of the design, and how changes in abstraction influence the language usability.

Abstractions can prove useful when dealing with computer programs, because non-trivial properties of computer programs are essentially undecidable (see Rice's theorem). As a consequence, automatic methods for deriving information on the behavior of computer programs either have to drop termination (on some occasions, they may fail, crash or never yield out a result), soundness (they may provide false information), or precision (they may answer "I don't know" to some questions).

Abstraction is the core concept of abstract interpretation. Model checking generally takes place on abstract versions of the studied systems.

Levels of abstraction

Main article: Abstraction layer

Computer science commonly presents levels (or, less commonly, layers) of abstraction, wherein each level represents a different model of the same information and processes, but with varying amounts of detail. Each level uses a system of expression involving a unique set of objects and compositions that apply only to a particular domain.  Each relatively abstract, "higher" level builds on a relatively concrete, "lower" level, which tends to provide an increasingly "granular" representation. For example, gates build on electronic circuits, binary on gates, machine language on binary, programming language on machine language, applications and operating systems on programming languages. Each level is embodied, but not determined, by the level beneath it, making it a language of description that is somewhat self-contained.

Database systems

Main article: Database management system

Since many users of database systems lack in-depth familiarity with computer data-structures, database developers often hide complexity through the following levels:

Data abstraction levels of a database system

Physical level: The lowest level of abstraction describes how a system actually stores data. The physical level describes complex low-level data structures in detail.

Logical level: The next higher level of abstraction describes what data the database stores, and what relationships exist among those data. The logical level thus describes an entire database in terms of a small number of relatively simple structures. Although implementation of the simple structures at the logical level may involve complex physical level structures, the user of the logical level does not need to be aware of this complexity. This is referred to as physical data independence. Database administrators, who must decide what information to keep in a database, use the logical level of abstraction.

View level: The highest level of abstraction describes only part of the entire database. Even though the logical level uses simpler structures, complexity remains because of the variety of information stored in a large database. Many users of a database system do not need all this information; instead, they need to access only a part of the database. The view level of abstraction exists to simplify their interaction with the system. The system may provide many views for the same database.

Layered architecture

Main article: Abstraction layer

The ability to provide a design of different levels of abstraction can

• simplify the design considerably
• enable different role players to effectively work at various levels of abstraction
• support the portability of software artifacts (model-based ideally)

Systems design and business process design can both use this. Some design processes specifically generate designs that contain various levels of abstraction.

Layered architecture partitions the concerns of the application into stacked groups (layers). It is a technique used in designing computer software, hardware, and communications in which system or network components are isolated in layers so that changes can be made in one layer without affecting the others.

Computing platform

From Wikipedia, the free encyclopedia

https://en.wikipedia.org/wiki/Computing_platform

A computing platform, digital platform, or software platform is an environment in which software is executed. It may be the hardware or the operating system (OS), a web browser and associated application programming interfaces, or other underlying software, as long as the program code is executed. Computing platforms have different abstraction levels, including a computer architecture, an OS, or runtime libraries. A computing platform is the stage on which computer programs can run.

A platform can be seen both as a constraint on the software development process, in that different platforms provide different functionality and restrictions; and as an assistant to the development process, in that they provide low-level functionality ready-made. For example, an OS may be a platform that abstracts the underlying differences in hardware and provides a generic command for saving files or accessing the network.

Components

Platforms may also include:

• Hardware alone, in the case of small embedded systems. Embedded systems can access hardware directly, without an OS; this is referred to as running on "bare metal".
• A browser in the case of web-based software. The browser itself runs on a hardware+OS platform, but this is not relevant to software running within the browser.
• An application, such as a spreadsheet or word processor, which hosts software written in an application-specific scripting language, such as an Excel macro. This can be extended to writing fully-fledged applications with the Microsoft Office suite as a platform.
• Software frameworks that provide ready-made functionality.
• Cloud computing and Platform as a Service. Extending the idea of a software framework, these allow application developers to build software out of components that are hosted not by the developer, but by the provider, with internet communication linking them together. The social networking sites Twitter and Facebook are also considered development platforms.
• A virtual machine (VM) such as the Java virtual machine or .NET CLR. Applications are compiled into a format similar to machine code, known as bytecode, which is then executed by the VM.
• A virtualized version of a complete system, including virtualized hardware, OS, software, and storage. These allow, for instance, a typical Windows program to run on what is physically a Mac.

Some architectures have multiple layers, with each layer acting as a platform for the one above it. In general, a component only has to be adapted to the layer immediately beneath it. For instance, a Java program has to be written to use the Java virtual machine (JVM) and associated libraries as a platform but does not have to be adapted to run on the Windows, Linux or Macintosh OS platforms. However, the JVM, the layer beneath the application, does have to be built separately for each OS.