Algorithm characterizations are attempts to formalize the word algorithm. Algorithm does not have a generally accepted formal definition. Researchers are actively working on this problem. This article will present some of the "characterizations" of the notion of "algorithm" in more detail. == The problem of definition == Over the last 200 years, the definition of the algorithm has become more complicated and detailed as researchers have tried to pin down the term. Indeed, there may be more than one type of "algorithm". But most agree that algorithm has something to do with defining generalized processes for the creation of "output" integers from other "input" integers – "input parameters" arbitrary and infinite in extent, or limited in extent but still variable—by the manipulation of distinguishable symbols (counting numbers) with finite collections of rules that a person can perform with paper and pencil. The most common number-manipulation schemes—both in formal mathematics and in routine life—are: (1) the recursive functions calculated by a person with paper and pencil, and (2) the Turing machine or its Turing equivalents—the primitive register-machine or "counter-machine" model, the random-access machine model (RAM), the random-access stored-program machine model (RASP) and its functional equivalent "the computer". When we are doing "arithmetic" we are really calculating by the use of "recursive functions" in the shorthand algorithms we learned in grade school, for example, adding and subtracting. The proofs that every "recursive function" we can calculate by hand we can compute by machine and vice versa—note the usage of the words calculate versus compute—is remarkable. But this equivalence together with the thesis (unproven assertion) that this includes every calculation/computation indicates why so much emphasis has been placed upon the use of Turing-equivalent machines in the definition of specific algorithms, and why the definition of "algorithm" itself often refers back to "the Turing machine". This is discussed in more detail under Stephen Kleene's characterization. The following are summaries of the more famous characterizations (Kleene, Markov, Knuth) together with those that introduce novel elements—elements that further expand the definition or contribute to a more precise definition. [ A mathematical problem and its result can be considered as two points in a space, and the solution consists of a sequence of steps or a path linking them. Quality of the solution is a function of the path. There might be more than one attribute defined for the path, e.g. length, complexity of shape, an ease of generalizing, difficulty, and so on. ] == Chomsky hierarchy == There is more consensus on the "characterization" of the notion of "simple algorithm". All algorithms need to be specified in a formal language, and the "simplicity notion" arises from the simplicity of the language. The Chomsky (1956) hierarchy is a containment hierarchy of classes of formal grammars that generate formal languages. It is used for classifying of programming languages and abstract machines. From the Chomsky hierarchy perspective, if the algorithm can be specified on a simpler language (than unrestricted), it can be characterized by this kind of language, else it is a typical "unrestricted algorithm". Examples: a "general purpose" macro language, like M4 is unrestricted (Turing complete), but the C preprocessor macro language is not, so any algorithm expressed in C preprocessor is a "simple algorithm". See also Relationships between complexity classes. == Features of a good algorithm == The following are desirable features of a well-defined algorithm, as discussed in Scheider and Gersting (1995): Unambiguous Operations: an algorithm must have specific, outlined steps. The steps should be exact enough to precisely specify what to do at each step. Well-Ordered: The exact order of operations performed in an algorithm should be concretely defined. Feasibility: All steps of an algorithm should be possible (also known as effectively computable). Input: an algorithm should be able to accept a well-defined set of inputs. Output: an algorithm should produce some result as an output, so that its correctness can be reasoned about. Finiteness: an algorithm should terminate after a finite number of instructions. Properties of specific algorithms that may be desirable include space and time efficiency, generality (i.e. being able to handle many inputs), or determinism. == 1881 John Venn's negative reaction to W. Stanley Jevons's Logical Machine of 1870 == In early 1870 W. Stanley Jevons presented a "Logical Machine" (Jevons 1880:200) for analyzing a syllogism or other logical form e.g. an argument reduced to a Boolean equation. By means of what Couturat (1914) called a "sort of logical piano [,] ... the equalities which represent the premises ... are "played" on a keyboard like that of a typewriter. ... When all the premises have been "played", the panel shows only those constituents whose sum is equal to 1, that is, ... its logical whole. This mechanical method has the advantage over VENN's geometrical method..." (Couturat 1914:75). For his part John Venn, a logician contemporary to Jevons, was less than thrilled, opining that "it does not seem to me that any contrivances at present known or likely to be discovered really deserve the name of logical machines" (italics added, Venn 1881:120). But of historical use to the developing notion of "algorithm" is his explanation for his negative reaction with respect to a machine that "may subserve a really valuable purpose by enabling us to avoid otherwise inevitable labor": (1) "There is, first, the statement of our data in accurate logical language", (2) "Then secondly, we have to throw these statements into a form fit for the engine to work with – in this case the reduction of each proposition to its elementary denials", (3) "Thirdly, there is the combination or further treatment of our premises after such reduction," (4) "Finally, the results have to be interpreted or read off. This last generally gives rise to much opening for skill and sagacity." He concludes that "I cannot see that any machine can hope to help us except in the third of these steps; so that it seems very doubtful whether any thing of this sort really deserves the name of a logical engine."(Venn 1881:119–121). == 1943, 1952 Stephen Kleene's characterization == This section is longer and more detailed than the others because of its importance to the topic: Kleene was the first to propose that all calculations/computations—of every sort, the totality of—can equivalently be (i) calculated by use of five "primitive recursive operators" plus one special operator called the mu-operator, or be (ii) computed by the actions of a Turing machine or an equivalent model. Furthermore, he opined that either of these would stand as a definition of algorithm. A reader first confronting the words that follow may well be confused, so a brief explanation is in order. Calculation means done by hand, computation means done by Turing machine (or equivalent). (Sometimes an author slips and interchanges the words). A "function" can be thought of as an "input-output box" into which a person puts natural numbers called "arguments" or "parameters" (but only the counting numbers including 0—the nonnegative integers) and gets out a single nonnegative integer (conventionally called "the answer"). Think of the "function-box" as a little man either calculating by hand using "general recursion" or computing by Turing machine (or an equivalent machine). "Effectively calculable/computable" is more generic and means "calculable/computable by some procedure, method, technique ... whatever...". "General recursive" was Kleene's way of writing what today is called just "recursion"; however, "primitive recursion"—calculation by use of the five recursive operators—is a lesser form of recursion that lacks access to the sixth, additional, mu-operator that is needed only in rare instances. Thus most of life goes on requiring only the "primitive recursive functions." === 1943 "Thesis I", 1952 "Church's Thesis" === In 1943 Kleene proposed what has come to be known as Church's thesis: "Thesis I. Every effectively calculable function (effectively decidable predicate) is general recursive" (First stated by Kleene in 1943 (reprinted page 274 in Davis, ed. The Undecidable; appears also verbatim in Kleene (1952) p.300) In a nutshell: to calculate any function the only operations a person needs (technically, formally) are the 6 primitive operators of "general" recursion (nowadays called the operators of the mu recursive functions). Kleene's first statement of this was under the section title "12. Algorithmic theories". He would later amplify it in his text (1952) as follows: "Thesis I and its converse provide the exact definition of the notion of a calculation (decision) procedure or algorithm, for the
System context diagram
A system context diagram in engineering is a diagram that defines the boundary between the system, or part of a system, and its environment, showing the entities that interact with it. This diagram is a high level view of a system. It is similar to a block diagram. == Overview == System context diagrams show a system, as a whole and its inputs and outputs from/to external factors. According to Kossiakoff and Sweet (2011): System Context Diagrams ... represent all external entities that may interact with a system ... Such a diagram pictures the system at the center, with no details of its interior structure, surrounded by all its interacting systems, environments and activities. The objective of the system context diagram is to focus attention on external factors and events that should be considered in developing a complete set of systems requirements and constraints. System context diagrams are used early in a project to get agreement on the scope under investigation. Context diagrams are typically included in a requirements document. These diagrams must be read by all project stakeholders and thus should be written in plain language, so the stakeholders can understand items within the document. == Building blocks == Context diagrams can be developed with the use of two types of building blocks: Entities (Actors): labeled boxes; one in the center representing the system, and around it multiple boxes for each external actor Relationships: labeled lines between the entities and system For example, "customer places order." Context diagrams can also use many different drawing types to represent external entities. They can use ovals, stick figures, pictures, clip art or any other representation to convey meaning. Decision trees and data storage are represented in system flow diagrams. A context diagram can also list the classifications of the external entities as one of a set of simple categories (Examples:), which add clarity to the level of involvement of the entity with regards to the system. These categories include: Active: Dynamic to achieve some goal or purpose (Examples: "Article readers" or "customers"). Passive: Static external entities which infrequently interact with the system (Examples: "Article editors" or "database administrator"). Cooperative: Predictable external entities which are used by the system to bring about some desired outcome (Examples: "Internet service providers" or "shipping companies"). Autonomous (Independent): External entities which are separated from the system, but affect the system indirectly, by means of imposed constraints or similar influences (Examples: "regulatory committees" or "standards groups"). == Alternatives == The best system context diagrams are used to display how a system interoperates at a very high level, or how systems operate and interact logically. The system context diagram is a necessary tool in developing a baseline interaction between systems and actors; actors and a system or systems and systems. Alternatives to the system context diagram are: Architecture Interconnect Diagram: The figure gives an example of an Architecture Interconnect Diagram: A representation of the Albuquerque regional ITS architecture interconnects for the Albuquerque Police Department that was generated using the Turbo Architecture tool is shown in the figure. Each block represents an ITS inventory element, including the name of the stakeholder in the top shaded portion. The interconnect lines between elements are solid or dashed, indicating existing or planned connections. Business Model Canvas, a strategic management template for developing new or documenting existing business models. It is a visual chart with elements describing a firm's value proposition, infrastructure, customers, and finances.[1] It assists firms in aligning their activities by illustrating potential trade-offs. Enterprise data model: this type of data model according to Simsion (2005) can contain up to 50 to 200 entity classes, which results from specific "high level of generalization in data modeling". IDEF0 Top Level Context Diagram: The IDEF0 process starts with the identification of the prime function to be decomposed. This function is identified on a "Top Level Context Diagram" that defines the scope of the particular IDEF0 analysis. Problem Diagrams (Problem Frames): In addition to the kinds of things shown on a context diagram, a problem diagram shows requirements and requirements references. Use case diagram: One of the Unified Modeling Language diagrams. They also represent the scope of the project at a similar level of abstraction. - Use Cases, however, tend to focus more on the goals of 'actors' who interact with the system, and do not specify any solution. Use Case diagrams represent a set of Use Cases, which are textual descriptions of how an actor achieves the goal of a use case. for Example Customer Places Order. ArchiMate: ArchiMate is an open and independent enterprise architecture modeling language to support the description, analysis and visualization of architecture within and across business domains in an unambiguous way. Most of these diagrams work well as long as a limited number of interconnects will be shown. Where twenty or more interconnects must be displayed, the diagrams become quite complex and can be difficult to read.
Artificial intelligence in customer experience
Artificial intelligence in customer experience is the use and development of artificial intelligence (AI) to aid and improve customer experience (sometimes abbreviated to CX AI). Chatbots are often seen as the first step in the development of AI within the industry, but more tailored offerings are slowly becoming available. The use of artificial intelligence in the space has since become more diverse than simply chatbots, with AI underpinning entire CX cloud platforms now used at major corporations. Contact center as a service (CCaaS) has become a core solution of the CX (customer experience) industry, with the CCaaS market size expected to reach $17.19 Billion by 2030 in the United States alone. == History == As with many AI applications, CX AI early implementation case studies have demonstrated that AI can increase the quality of customer interactions and therefore the overall experience that organizations can provide. This in turn has suggested a higher return on investment and/or revenue as a result. The beginning of the revolution of customer experience and the use of machine learning was with chatbots. The use of this type of AI can be traced back to Alan Turing in 1950, when the Church–Turing thesis suggested that computers could use "formal reasoning" to reach conclusions. In 2017, Meta produced one of the first breakthroughs for everyday use of AI for customer experience when it allowed Facebook users to create their own messaging bots for free on its Facebook messenger platform. The main focus of this was to both automate and improve customer experience and interaction. In 2023, CCaaS vendors began announcing the integration of ChatGPT’s generative AI into their CX solutions. Generative AI adds a layer of semantics into AI outputs. This was a major breakthrough for conversational AI. Using natural language processing and conversational AI, chatbots could enhance the level of service they could provide, speaking to customers in an easy-to-understand and conversational tone. == Applications == Currently the main location for the application of CX AI in the sector is in contact centers. Historically, contact centers were simply known as call centers, but in recent years differentiation developed between the two terms. Call centers provide phone support, while contact centers also provide support via digital channels in addition to analogue phone systems. Contact centers are therefore seen as a complete customer service solution, where as call centers simply cover one aspect of customer interactions. As a part of improving CX, AI is also improving the employee experience. AI is able to automate tasks to free up time for contact center agents to focus on higher priority tasks. For example, AI can be used for auto summarization. This means that instead of human agents having to summarize customer interactions now AI can do it, saving organizations time and money.
Argument mining
Argument mining, or argumentation mining, is a research area within the natural language processing field. The goal of argument mining is the automatic extraction and identification of argumentative structures from natural language text with the aid of computer programs. Such argumentative structures include the premise, conclusions, the argument scheme and the relationship between the main and subsidiary argument, or the main and counter-argument within discourse. The Argument Mining workshop series is the main research forum for argument mining related research. == Applications == Argument mining has been applied in many different genres including the qualitative assessment of social media content (e.g. Twitter, Facebook), where it provides a powerful tool for policy-makers and researchers in social and political sciences. Other domains include legal documents, product reviews, scientific articles, online debates, newspaper articles and dialogical domains. Transfer learning approaches have been successfully used to combine the different domains into a domain agnostic argumentation model. Argument mining has been used to provide students individual writing support by accessing and visualizing the argumentation discourse in their texts. The application of argument mining in a user-centered learning tool helped students to improve their argumentation skills significantly compared to traditional argumentation learning applications. == Challenges == Given the wide variety of text genres and the different research perspectives and approaches, it has been difficult to reach a common and objective evaluation scheme. Many annotated data sets have been proposed, with some gaining popularity, but a consensual data set is yet to be found. Annotating argumentative structures is a highly demanding task. There have been successful attempts to delegate such annotation tasks to the crowd but the process still requires a lot of effort and carries significant cost. Initial attempts to bypass this hurdle were made using the weak supervision approach.
Stanhope Demonstrator
The Stanhope Demonstrator was the first machine to solve problems in logic. It was designed by Charles Stanhope, 3rd Earl Stanhope to demonstrate consequences in logic symbolically. The first model was constructed in 1775. It consisted of two slides coloured red and gray mounted in a square brass frame. This could be used to demonstrate the solution to a syllogistic type of problem in which objects might have two different properties and the question was how many would have both properties. Scales marked zero to ten were used to set the numbers or proportions of objects with the two properties. This form of inference anticipated the numerically definite syllogism which Augustus De Morgan laid out in his book, Formal Logic, in 1847. == Construction == The device was a brass plate about four inches square which was mounted on a piece of mahogany which was three-quarters of an inch thick. There was an opening with a depression in the wood about one and a half inches square and half an inch deep. This opening was called the holon, meaning "whole", and represented the full set of objects under consideration. A slide of red translucent glass could be inserted from the right across the holon. A slide of gray wood could be slid under the red slide. When the device was used for the "Rule for the Logic of Certainty", the gray slider was inserted from the left. When it was used for the "Rule for the Logic of Probability", the gray slider was inserted from above. The red and the gray sliders represented the two affirmative propositions which were being combined. Stanhope called these ho and los. At least four of the devices with this square style were built. In 1879, Robert Harley wrote that he had one which he had been given by Stanhope's great-grandson, Arthur, who had kept one. The other two were owned by Henry Prevost Babbage – the son of Charles Babbage, who continued his work on the Analytical Engine. One of the devices was donated to the Science Museum, London by the last Earl in 1953. Other styles, such as circular models, were constructed, but these were less convenient.
VACUUM
VACUUM is a set of normative guidance principles for achieving training and test dataset quality for structured datasets in data science and machine learning. The garbage-in, garbage out principle motivates a solution to the problem of data quality but does not offer a specific solution. Unlike the majority of the ad-hoc data quality assessment metrics often used by practitioners VACUUM specifies qualitative principles for data quality management and serves as a basis for defining more detailed quantitative metrics of data quality. VACUUM is an acronym that stands for: valid accurate consistent uniform unified model
Theaitre
Theaitre (stylized as THEaiTRE) is an interdisciplinary research project investigating to what extent artificial intelligence is able to generate theatre play scripts. The first theatre play produced within the project, AI: When a Robot Writes a Play, premiered online on February 26, 2021. == Goal == Following similar previous projects such as Sunspring, a short sci-fi movie with an automatically generated script, the THEaiTRE project investigates whether current language generation approaches are mature enough to generate a theatre play script that could be successfully performed in front of an audience. The project falls within the area of generative art, famously represented e.g. by the portrait of Edmond de Belamy which was generated by an artificial neural network. In this field, artists are trying to use automated techniques to create "art", questioning the modern definition of art itself. More broadly, the project aims at promoting cooperation rather than competition of humans and artificial intelligence as the more beneficial approach for both. The first theatre play created within the project, titled AI: When a Robot Writes a Play, was presented in February 2021 at the 100th anniversary of the premiere of the R.U.R. theatre play by the Czech author Karel Čapek to celebrate the invention of the word "robot". While R.U.R. was a play written by a human about robots (and humans), THEaiTRE tried to reverse this idea by presenting a play written by a "robot" (artificial intelligence) about humans (and robots). The script of the play was published online, with marked parts of the text which were written manually or manually post-edited. The analysis shows that 90% of the script is automatically generated, with 10% manually written or manually post-edited. The project also plans to produce a second play in 2022, addressing some of the many shortcomings of the approach used to generate the first play, as well as attempting to further minimize the amount of human influence on the script. == Approach == At the core of the project is the GPT-2 language model by OpenAI with various adjustments motivated by the task of generating theatre play scripts, for which the model is not particularly trained. The GPT-2 model is used in the usual way, providing it with a start of a document and prompting it to generate a continuation of the document. Specifically, the input for GPT-2 in this project is typically a short description of the scene setting, followed by a few lines to introduce the characters and start the dialogue. The model then generates 10 continuation lines, and hands control to the user, who can then either ask the model to continue generating, or make various edits before letting the model to generate further, deleting some parts of the script or adding new lines into the script. The adjustments include restricting the generator to only produce lines pertaining to characters appearing in the input prompt, limiting the repetitiveness of the generated text, and employing automatic summarization of the input prompt and the generated text to overcome the limitation of the GPT-2 model which only attends to the last 1,024 subword tokens. The limitations of the model include, among other, a lack of distinctiveness and self-consistency of the characters, an inability to generate the script for the whole play (scripts for individual scenes are generated independently), and errors due to the employment of automated machine translation, as GPT-2 generates English texts but the final play script is being produced in Czech language. The source codes of the project are available under the MIT licence. The project has also published some sample outputs. == Team == The project is a cooperation of the following experts, all based in Prague, Czech Republic: computational linguists from the Faculty of Mathematics and Physics, Charles University theatre experts from the Švanda Theatre and from the Theatre Faculty of the Academy of Performing Arts in Prague hackers from CEE Hacks The project is financially supported by the Technology Agency of the Czech Republic.