Mountain Car, a standard testing domain in Reinforcement learning, is a problem in which an under-powered car must drive up a steep hill. Since gravity is stronger than the car's engine, even at full throttle, the car cannot simply accelerate up the steep slope. The car is situated in a valley and must learn to leverage potential energy by driving up the opposite hill before the car is able to make it to the goal at the top of the rightmost hill. The domain has been used as a test bed in various reinforcement learning papers. == Introduction == The mountain car problem, although fairly simple, is commonly applied because it requires a reinforcement learning agent to learn on two continuous variables: position and velocity. For any given state (position and velocity) of the car, the agent is given the possibility of driving left, driving right, or not using the engine at all. In the standard version of the problem, the agent receives a negative reward at every time step when the goal is not reached; the agent has no information about the goal until an initial success. == History == The mountain car problem appeared first in Andrew Moore's PhD thesis (1990). It was later more strictly defined in Singh and Sutton's reinforcement learning paper with eligibility traces. The problem became more widely studied when Sutton and Barto added it to their book Reinforcement Learning: An Introduction (1998). Throughout the years many versions of the problem have been used, such as those which modify the reward function, termination condition, and the start state. == Techniques used to solve mountain car == Q-learning and similar techniques for mapping discrete states to discrete actions need to be extended to be able to deal with the continuous state space of the problem. Approaches often fall into one of two categories, state space discretization or function approximation. === Discretization === In this approach, two continuous state variables are pushed into discrete states by bucketing each continuous variable into multiple discrete states. This approach works with properly tuned parameters but a disadvantage is information gathered from one state is not used to evaluate another state. Tile coding can be used to improve discretization and involves continuous variables mapping into sets of buckets offset from one another. Each step of training has a wider impact on the value function approximation because when the offset grids are summed, the information is diffused. === Function approximation === Function approximation is another way to solve the mountain car. By choosing a set of basis functions beforehand, or by generating them as the car drives, the agent can approximate the value function at each state. Unlike the step-wise version of the value function created with discretization, function approximation can more cleanly estimate the true smooth function of the mountain car domain. === Eligibility traces === One aspect of the problem involves the delay of actual reward. The agent is not able to learn about the goal until a successful completion. Given a naive approach for each trial the car can only backup the reward of the goal slightly. This is a problem for naive discretization because each discrete state will only be backed up once, taking a larger number of episodes to learn the problem. This problem can be alleviated via the mechanism of eligibility traces, which will automatically backup the reward given to states before, dramatically increasing the speed of learning. Eligibility traces can be viewed as a bridge from temporal difference learning methods to Monte Carlo methods. == Technical details == The mountain car problem has undergone many iterations. This section focuses on the standard well-defined version from Sutton (2008). === State variables === Two-dimensional continuous state space. V e l o c i t y = ( − 0.07 , 0.07 ) {\displaystyle Velocity=(-0.07,0.07)} P o s i t i o n = ( − 1.2 , 0.6 ) {\displaystyle Position=(-1.2,0.6)} === Actions === One-dimensional discrete action space. m o t o r = ( l e f t , n e u t r a l , r i g h t ) {\displaystyle motor=(left,neutral,right)} === Reward === For every time step: r e w a r d = − 1 {\displaystyle reward=-1} === Update function === For every time step: A c t i o n = [ − 1 , 0 , 1 ] {\displaystyle Action=[-1,0,1]} V e l o c i t y = V e l o c i t y + ( A c t i o n ) ∗ 0.001 + cos ( 3 ∗ P o s i t i o n ) ∗ ( − 0.0025 ) {\displaystyle Velocity=Velocity+(Action)0.001+\cos(3Position)(-0.0025)} P o s i t i o n = P o s i t i o n + V e l o c i t y {\displaystyle Position=Position+Velocity} === Starting condition === Optionally, many implementations include randomness in both parameters to show better generalized learning. P o s i t i o n = − 0.5 {\displaystyle Position=-0.5} V e l o c i t y = 0.0 {\displaystyle Velocity=0.0} === Termination condition === End the simulation when: P o s i t i o n ≥ 0.6 {\displaystyle Position\geq 0.6} == Variations == There are many versions of the mountain car which deviate in different ways from the standard model. Variables that vary include but are not limited to changing the constants (gravity and steepness) of the problem so specific tuning for specific policies become irrelevant and altering the reward function to affect the agent's ability to learn in a different manner. An example is changing the reward to be equal to the distance from the goal, or changing the reward to zero everywhere and one at the goal. Additionally, a 3D mountain car can be used, with a 4D continuous state space.
Site reliability engineering
Site reliability engineering (SRE) is a discipline in the field of software engineering and IT infrastructure support that monitors and improves the availability and performance of deployed software systems and large software services (which are expected to deliver reliable response times across events such as new software deployments, hardware failures, and cybersecurity attacks). There is typically a focus on automation and an infrastructure as code methodology. SRE uses elements of software engineering, IT infrastructure, web development, and operations to assist with reliability. It is similar to DevOps as they both aim to improve the reliability and availability of deployed software systems. == History == Site Reliability Engineering originated at Google with Benjamin Treynor Sloss, who founded SRE team in 2003. The concept expanded within the software development industry, leading various companies to employ site reliability engineers. By March 2016, Google had more than 1,000 site reliability engineers on staff. Dedicated SRE teams are common at larger web development companies. In middle-sized and smaller companies, DevOps teams sometimes perform SRE, as well. Organizations that have adopted the concept include Airbnb, Dropbox, IBM, LinkedIn, Netflix, and Wikimedia. == Definition == Site reliability engineers (SREs) are responsible for a combination of system availability, latency, performance, efficiency, change management, monitoring, emergency response, and capacity planning. SREs often have backgrounds in software engineering, systems engineering, and/or system administration. The focuses of SRE include automation, system design, and improvements to system resilience. SRE is considered a specific implementation of DevOps; focusing specifically on building reliable systems, whereas DevOps covers a broader scope of operations. Despite having different focuses, some companies have rebranded their operations teams to SRE teams. == Principles and practices == Common definitions of the practices include (but are not limited to): Automation of repetitive tasks for cost-effectiveness. Defining reliability goals to prevent endless effort. Design of systems with a goal to reduce risks to availability, latency, and efficiency. Observability, the ability to ask arbitrary questions about a system without having to know ahead of time what to ask. Common definitions of the principles include (but are not limited to): Toil management, the implementation of the first principle outlined above. Defining and measuring reliability goals—SLIs, SLOs, and error budgets. Non-Abstract Large Scale Systems Design (NALSD) with a focus on reliability. Designing for and implementing observability. Defining, testing, and running an incident management process. Capacity planning. Change and release management, including CI/CD. Chaos engineering. == Deployment == SRE teams collaborate with other departments within organizations to guide the implementation of the mentioned principles. Below is an overview of common practices: === Kitchen Sink === Kitchen Sink refers to the expansive and often unbounded scope of services and workflows that SRE teams oversee. Unlike traditional roles with clearly defined boundaries, SREs are tasked with various responsibilities, including system performance optimization, incident management, and automation. This approach allows SREs to address multiple challenges, ensuring that systems run efficiently and evolve in response to changing demands and complexities. === Infrastructure === Infrastructure SRE teams focus on maintaining and improving the reliability of systems that support other teams' workflows. While they sometimes collaborate with platform engineering teams, their primary responsibility is ensuring up-time, performance, and efficiency. Platform teams, on the other hand, primarily develop the software and systems used across the organization. While reliability is a goal for both, platform teams prioritize creating and maintaining the tools and services used by internal stakeholders, whereas Infrastructure SRE teams are tasked with ensuring those systems run smoothly and meet reliability standards. === Tools === SRE teams utilize a variety of tools with the aim of measuring, maintaining, and enhancing system reliability. These tools play a role in monitoring performance, identifying issues, and facilitating proactive maintenance. For instance, Nagios Core is commonly employed for system monitoring and alerting, while Prometheus (software) is frequently used for collecting and querying metrics in cloud-native environments. === Product or Application === SRE teams dedicated to specific products or applications are common in large organizations. These teams are responsible for ensuring the reliability, scalability, and performance of key services. In larger companies, it's typical to have multiple SRE teams, each focusing on different products or applications, ensuring that each area receives specialized attention to meet performance and availability targets. === Embedded === In an embedded model, individual SREs or small SRE pairs are integrated within software engineering teams. These SREs collaborate with developers, applying core SRE principles—such as automation, monitoring, and incident response—directly to the software development lifecycle. This approach aims to enhance reliability, performance, and collaboration between SREs and developers. === Consulting === Consulting SRE teams specialize in advising organizations on the implementation of SRE principles and practices. Typically composed of seasoned SREs with a history across various implementations, these teams provide insights and guidance for specific organizational needs. When working directly with clients, these SREs are often referred to as 'Customer Reliability Engineers.' In large organizations that have adopted SRE, a hybrid model is common. This model includes various implementations, such as multiple Product/Application SRE teams dedicated to addressing the specific reliability needs of different products. An Infrastructure SRE team may collaborate with a Platform engineering group to achieve shared reliability goals for a unified platform that supports all products and applications. == Industry == Since 2014, the USENIX organization has hosted the annual SREcon conference, bringing together site reliability engineers from various industries. This conference is a platform for professionals to share knowledge, explore effective practices, and discuss trends in site reliability engineering.
Lernmatrix
Lernmatrix (German for "learning matrix") is a special type of artificial neural network (ANN) architecture, similar to associative memory, invented around 1960 by Karl Steinbuch, a pioneer in computer science and ANNs. This model for learning systems could establish complex associations between certain sets of characteristics (e.g., letters of an alphabet) and their meanings. == Function == The Lernmatrix generally consists of n "characteristic lines" and m "meaning lines," where each characteristic line is connected to each meaning line, similar to how neurons in the brain are connected by synapses. (This can be realized in various ways – according to Steinbuch, this could be done by hardware or software). To train a Lernmatrix, values are specified on the corresponding characteristic and meaning lines (binary or real); then the connections between all pairs of characteristic and meaning lines are strengthened by the Hebb rule. A trained Lernmatrix, when given a specific input on the characteristic lines, activates the corresponding meaning lines. In modern language, it is a linear projection module. By appropriately interconnecting several Lernmatrices, a switching system can be built that, after completing certain training phases, is ultimately able to automatically determine the most probable associated meaning for an input sequence of features.
Learning rule
An artificial neural network's learning rule or learning process is a method, mathematical logic or algorithm which improves the network's performance and/or training time. Usually, this rule is applied repeatedly over the network. It is done by updating the weight and bias levels of a network when it is simulated in a specific data environment. A learning rule may accept existing conditions (weights and biases) of the network, and will compare the expected result and actual result of the network to give new and improved values for the weights and biases. Depending on the complexity of the model being simulated, the learning rule of the network can be as simple as an XOR gate or mean squared error, or as complex as the result of a system of differential equations. The learning rule is one of the factors which decides how fast or how accurately the neural network can be developed. Depending on the process to develop the network, there are three main paradigms of machine learning: supervised learning, unsupervised learning, and reinforcement learning. == Background == A lot of the learning methods in machine learning work similar to each other, and are based on each other, which makes it difficult to classify them in clear categories. But they can be broadly understood in 4 categories of learning methods, though these categories don't have clear boundaries and they tend to belong to multiple categories of learning methods - Hebbian - Neocognitron, Brain-state-in-a-box Gradient Descent - ADALINE, Hopfield Network, Recurrent Neural Network Competitive - Learning Vector Quantisation, Self-Organising Feature Map, Adaptive Resonance Theory Stochastic - Boltzmann Machine, Cauchy Machine Though these learning rules might appear to be based on similar ideas, they do have subtle differences, as they are a generalisation or application over the previous rule, and hence it makes sense to study them separately based on their origins and intents. === Hebbian Learning === Developed by Donald Hebb in 1949 to describe biological neuron firing. In the mid-1950s it was also applied to computer simulations of neural networks. Δ w i = η x i y {\displaystyle \Delta w_{i}=\eta x_{i}y} Where η {\displaystyle \eta } represents the learning rate, x i {\displaystyle x_{i}} represents the input of neuron i, and y is the output of the neuron. It has been shown that Hebb's rule in its basic form is unstable. Oja's Rule, BCM Theory are other learning rules built on top of or alongside Hebb's Rule in the study of biological neurons. ==== Perceptron Learning Rule (PLR) ==== The perceptron learning rule originates from the Hebbian assumption, and was used by Frank Rosenblatt in his perceptron in 1958. The net is passed to the activation (transfer) function and the function's output is used for adjusting the weights. The learning signal is the difference between the desired response and the actual response of a neuron. The step function is often used as an activation function, and the outputs are generally restricted to -1, 0, or 1. The weights are updated with w new = w old + η ( t − o ) x i {\displaystyle w_{\text{new}}=w_{\text{old}}+\eta (t-o)x_{i}} where "t" is the target value and "o" is the output of the perceptron, and η {\displaystyle \eta } is called the learning rate. The algorithm converges to the correct classification if: the training data is linearly separable η {\displaystyle \eta } is sufficiently small (though smaller η {\displaystyle \eta } generally means a longer learning time and more epochs) It should also be noted that a single layer perceptron with this learning rule is incapable of working on linearly non-separable inputs, and hence the XOR problem cannot be solved using this rule alone === Backpropagation === Seppo Linnainmaa in 1970 is said to have developed the Backpropagation Algorithm but the origins of the algorithm go back to the 1960s with many contributors. It is a generalisation of the least mean squares algorithm in the linear perceptron and the Delta Learning Rule. It implements gradient descent search through the space possible network weights, iteratively reducing the error, between the target values and the network outputs. ==== Widrow-Hoff Learning (Delta Learning Rule) ==== Similar to the perceptron learning rule but with different origin. It was developed for use in the ADALINE network, which differs from the Perceptron mainly in terms of the training. The weights are adjusted according to the weighted sum of the inputs (the net), whereas in perceptron the sign of the weighted sum was useful for determining the output as the threshold was set to 0, -1, or +1. This makes ADALINE different from the normal perceptron. Delta rule (DR) is similar to the Perceptron Learning Rule (PLR), with some differences: Error (δ) in DR is not restricted to having values of 0, 1, or -1 (as in PLR), but may have any value DR can be derived for any differentiable output/activation function f, whereas in PLR only works for threshold output function Sometimes only when the Widrow-Hoff is applied to binary targets specifically, it is referred to as Delta Rule, but the terms seem to be used often interchangeably. The delta rule is considered to a special case of the back-propagation algorithm. Delta rule also closely resembles the Rescorla-Wagner model under which Pavlovian conditioning occurs. === Competitive Learning === Competitive learning is considered a variant of Hebbian learning, but it is special enough to be discussed separately. Competitive learning works by increasing the specialization of each node in the network. It is well suited to finding clusters within data. Models and algorithms based on the principle of competitive learning include vector quantization and self-organizing maps (Kohonen maps).
Cortica
Headquartered in Tel Aviv Cortica utilizes unsupervised learning methods to recognize and analyze digital images and video. The technology developed by the Cortica team is based on research of the function of the human brain. == Company Founding == Cortica was founded in 2007 by Igal Raichelgauz, Karina Odinaev and Yehoshua Zeevi. Together, the founders developed the company’s core technology while at Technion – Israel Institute of Technology. By combining discoveries in neuroscience with developments in computer programming, the team created technology that possesses the ability to interpret large amounts of visual data with increased accuracy. This technology, called Image2Text, is based on the founders’ work in digitally replicating cortical neural networks’ ability to identify complex patterns within massive quantities of ambiguous and noisy data. Cortica’s offerings have application in the automotive industry, media industries, as well as the smart city and medical industries. Industry experts suggest that the self-driving automotive industry alone will be worth upwards of $7 trillion while each connected car is expected to generate 4,000 GB of data per day. Beyond that, industry analysts expect the proliferation of surveillance cameras to continue leading to an expected 2,500 Petabytes of data being generated daily by new surveillance cameras. Cortica operates in these high scale industries. The company currently employs professionals from many domains including AI researchers as well as veterans of intelligence units within the Israeli Defense Forces. == Research and Technology == In 2006, Founders Raichelgauz, Odinaev, and Zeevi shared their findings with the 28th IEEE EMBS Annual International Conference in New York in a paper titled, “Natural Signal Classification by Neural Cliques and Phase-Locked Attractors”. That same year, the team also published “Cliques in Neural Ensembles as Perception Carriers" CB Insights recently identified Cortica as the number one patent holder among AI companies. Cortica is researching to develop a machine-learning driving system which can identify objects and pedestrians. Connecting to it, Elon Musk has been rumored to partner with Cortica for his electric car company, Tesla. However, Tesla denies it stating that Musk did not discuss a collaboration with artificial intelligence firm Cortica. == Funding == Cortica raised $7 million in its Series A funding round, announced in August 2012. Investors included Horizons Ventures (the investment firm of Hong Kong billionaire Li Ka-Shing), and Ynon Kreiz, the former chairman and CEO of the Endemol Group. In May 2013, it was announced that Cortica had raised $1.5 million from Russian firm Mail.ru Group. It later transpired that this was a part of Cortica's Series B funding round for $6.4 million, announced in June 2013. The round was led by Horizons Ventures, with participation from the Russian firm Mail.ru Group and other angel investors. In its fourth funding round, Cortica has raised $20 million, bringing the total investments to $38 million. According to a report from The Israeli lead Daily economic newspaper, TheMarker, the fourth round was led by a strategic Chinese investor who will probably help the company expand into the Asian market. == Media coverage == GigaOm listed Cortica as one of the top deep learning startups in a November 2013 article surveying the field, along with AlchemyAPI, Ersatz, and Semantria. Business Insider ranked Cortica as one of the coolest tech companies in Israel. CB Insights has identified Cortica as the top patent holding AI company. In 2017 several leading automotive media outlets covered the launch of Cortica's automotive business unit
Histogram of oriented displacements
Histogram of oriented displacements (HOD) is a 2D trajectory descriptor. The trajectory is described using a histogram of the directions between each two consecutive points. Given a trajectory T = {P1, P2, P3, ..., Pn}, where Pt is the 2D position at time t. For each pair of positions Pt and Pt+1, calculate the direction angle θ(t, t+1). Value of θ is between 0 and 360. A histogram of the quantized values of θ is created. If the histogram is of 8 bins, the first bin represents all θs between 0 and 45. The histogram accumulates the lengths of the consecutive moves. For each θ, a specific histogram bin is determined. The length of the line between Pt and Pt+1 is then added to the specific histogram bin. To show the intuition behind the descriptor, consider the action of waving hands. At the end of the action, the hand falls down. When describing this down movement, the descriptor does not care about the position from which the hand started to fall. This fall will affect the histogram with the appropriate angles and lengths, regardless of the position where the hand started to fall. HOD records for each moving point: how much it moves in each range of directions. HOD has a clear physical interpretation. It proposes that, a simple way to describe the motion of an object, is to indicate how much distance it moves in each direction. If the movement in all directions are saved accurately, the movement can be repeated from the initial position to the final destination regardless of the displacements order. However, the temporal information will be lost, as the order of movements is not stored-this is what we solve by applying the temporal pyramid, as shown in section \ref{sec:temp-pyramid}. If the angles quantization range is small, classifiers that use the descriptor will overfit. Generalization needs some slack in directions-which can be done by increasing the quantization range.
Ramification problem
In philosophy and artificial intelligence (especially, knowledge based systems), the ramification problem is concerned with the indirect consequences of an action. It might also be posed as how to represent what happens implicitly due to an action or how to control the secondary and tertiary effects of an action. It is strongly connected to, and is opposite the qualification side of, the frame problem. Limit theory helps in operational usage. For instance, in KBE derivation of a populated design (geometrical objects, etc., similar concerns apply in shape theory), equivalence assumptions allow convergence where potentially large, and perhaps even computationally indeterminate, solution sets are handled deftly. Yet, in a chain of computation, downstream events may very well find some types of results from earlier resolutions of ramification as problematic for their own algorithms.