Estimation of distribution algorithms (EDAs), sometimes called probabilistic model-building genetic algorithms (PMBGAs), are stochastic optimization methods that guide the search for the optimum by building and sampling explicit probabilistic models of promising candidate solutions. Optimization is viewed as a series of incremental updates of a probabilistic model, starting with the model encoding an uninformative prior over admissible solutions and ending with the model that generates only the global optima. EDAs belong to the class of evolutionary algorithms. The main difference between EDAs and most conventional evolutionary algorithms is that evolutionary algorithms generate new candidate solutions using an implicit distribution defined by one or more variation operators, whereas EDAs use an explicit probability distribution encoded by a Bayesian network, a multivariate normal distribution, or another model class. Similarly as other evolutionary algorithms, EDAs can be used to solve optimization problems defined over a number of representations from vectors to LISP style S expressions, and the quality of candidate solutions is often evaluated using one or more objective functions. The general procedure of an EDA is outlined in the following: t := 0 initialize model M(0) to represent uniform distribution over admissible solutions while (termination criteria not met) do P := generate N>0 candidate solutions by sampling M(t) F := evaluate all candidate solutions in P M(t + 1) := adjust_model(P, F, M(t)) t := t + 1 Using explicit probabilistic models in optimization allowed EDAs to feasibly solve optimization problems that were notoriously difficult for most conventional evolutionary algorithms and traditional optimization techniques, such as problems with high levels of epistasis. Nonetheless, the advantage of EDAs is also that these algorithms provide an optimization practitioner with a series of probabilistic models that reveal a lot of information about the problem being solved. This information can in turn be used to design problem-specific neighborhood operators for local search, to bias future runs of EDAs on a similar problem, or to create an efficient computational model of the problem. For example, if the population is represented by bit strings of length 4, the EDA can represent the population of promising solution using a single vector of four probabilities (p1, p2, p3, p4) where each component of p defines the probability of that position being a 1. Using this probability vector it is possible to create an arbitrary number of candidate solutions. == Estimation of distribution algorithms (EDAs) == This section describes the models built by some well known EDAs of different levels of complexity. It is always assumed a population P ( t ) {\displaystyle P(t)} at the generation t {\displaystyle t} , a selection operator S {\displaystyle S} , a model-building operator α {\displaystyle \alpha } and a sampling operator β {\displaystyle \beta } . == Univariate factorizations == The most simple EDAs assume that decision variables are independent, i.e. p ( X 1 , X 2 ) = p ( X 1 ) ⋅ p ( X 2 ) {\displaystyle p(X_{1},X_{2})=p(X_{1})\cdot p(X_{2})} . Therefore, univariate EDAs rely only on univariate statistics and multivariate distributions must be factorized as the product of N {\displaystyle N} univariate probability distributions, D Univariate := p ( X 1 , … , X N ) = ∏ i = 1 N p ( X i ) . {\displaystyle D_{\text{Univariate}}:=p(X_{1},\dots ,X_{N})=\prod _{i=1}^{N}p(X_{i}).} Such factorizations are used in many different EDAs, next we describe some of them. === Univariate marginal distribution algorithm (UMDA) === The UMDA is a simple EDA that uses an operator α U M D A {\displaystyle \alpha _{UMDA}} to estimate marginal probabilities from a selected population S ( P ( t ) ) {\displaystyle S(P(t))} . By assuming S ( P ( t ) ) {\displaystyle S(P(t))} contain λ {\displaystyle \lambda } elements, α U M D A {\displaystyle \alpha _{UMDA}} produces probabilities: p t + 1 ( X i ) = 1 λ ∑ x ∈ S ( P ( t ) ) x i , ∀ i ∈ 1 , 2 , … , N . {\displaystyle p_{t+1}(X_{i})={\dfrac {1}{\lambda }}\sum _{x\in S(P(t))}x_{i},~\forall i\in 1,2,\dots ,N.} Every UMDA step can be described as follows D ( t + 1 ) = α UMDA ∘ S ∘ β λ ( D ( t ) ) . {\displaystyle D(t+1)=\alpha _{\text{UMDA}}\circ S\circ \beta _{\lambda }(D(t)).} === Population-based incremental learning (PBIL) === The PBIL, represents the population implicitly by its model, from which it samples new solutions and updates the model. At each generation, μ {\displaystyle \mu } individuals are sampled and λ ≤ μ {\displaystyle \lambda \leq \mu } are selected. Such individuals are then used to update the model as follows p t + 1 ( X i ) = ( 1 − γ ) p t ( X i ) + ( γ / λ ) ∑ x ∈ S ( P ( t ) ) x i , ∀ i ∈ 1 , 2 , … , N , {\displaystyle p_{t+1}(X_{i})=(1-\gamma )p_{t}(X_{i})+(\gamma /\lambda )\sum _{x\in S(P(t))}x_{i},~\forall i\in 1,2,\dots ,N,} where γ ∈ ( 0 , 1 ] {\displaystyle \gamma \in (0,1]} is a parameter defining the learning rate, a small value determines that the previous model p t ( X i ) {\displaystyle p_{t}(X_{i})} should be only slightly modified by the new solutions sampled. PBIL can be described as D ( t + 1 ) = α PIBIL ∘ S ∘ β μ ( D ( t ) ) {\displaystyle D(t+1)=\alpha _{\text{PIBIL}}\circ S\circ \beta _{\mu }(D(t))} === Compact genetic algorithm (cGA) === The CGA, also relies on the implicit populations defined by univariate distributions. At each generation t {\displaystyle t} , two individuals x , y {\displaystyle x,y} are sampled, P ( t ) = β 2 ( D ( t ) ) {\displaystyle P(t)=\beta _{2}(D(t))} . The population P ( t ) {\displaystyle P(t)} is then sorted in decreasing order of fitness, S Sort ( f ) ( P ( t ) ) {\displaystyle S_{{\text{Sort}}(f)}(P(t))} , with u {\displaystyle u} being the best and v {\displaystyle v} being the worst solution. The CGA estimates univariate probabilities as follows p t + 1 ( X i ) = p t ( X i ) + γ ( u i − v i ) , ∀ i ∈ 1 , 2 , … , N , {\displaystyle p_{t+1}(X_{i})=p_{t}(X_{i})+\gamma (u_{i}-v_{i}),\quad \forall i\in 1,2,\dots ,N,} where, γ ∈ ( 0 , 1 ] {\displaystyle \gamma \in (0,1]} is a constant defining the learning rate, usually set to γ = 1 / N {\displaystyle \gamma =1/N} . The CGA can be defined as D ( t + 1 ) = α CGA ∘ S Sort ( f ) ∘ β 2 ( D ( t ) ) {\displaystyle D(t+1)=\alpha _{\text{CGA}}\circ S_{{\text{Sort}}(f)}\circ \beta _{2}(D(t))} == Bivariate factorizations == Although univariate models can be computed efficiently, in many cases they are not representative enough to provide better performance than GAs. In order to overcome such a drawback, the use of bivariate factorizations was proposed in the EDA community, in which dependencies between pairs of variables could be modeled. A bivariate factorization can be defined as follows, where π i {\displaystyle \pi _{i}} contains a possible variable dependent to X i {\displaystyle X_{i}} , i.e. | π i | = 1 {\displaystyle |\pi _{i}|=1} . D Bivariate := p ( X 1 , … , X N ) = ∏ i = 1 N p ( X i | π i ) . {\displaystyle D_{\text{Bivariate}}:=p(X_{1},\dots ,X_{N})=\prod _{i=1}^{N}p(X_{i}|\pi _{i}).} Bivariate and multivariate distributions are usually represented as probabilistic graphical models (graphs), in which edges denote statistical dependencies (or conditional probabilities) and vertices denote variables. To learn the structure of a PGM from data linkage-learning is employed. === Mutual information maximizing input clustering (MIMIC) === The MIMIC factorizes the joint probability distribution in a chain-like model representing successive dependencies between variables. It finds a permutation of the decision variables, r : i ↦ j {\displaystyle r:i\mapsto j} , such that x r ( 1 ) x r ( 2 ) , … , x r ( N ) {\displaystyle x_{r(1)}x_{r(2)},\dots ,x_{r(N)}} minimizes the Kullback–Leibler divergence in relation to the true probability distribution, i.e. π r ( i + 1 ) = { X r ( i ) } {\displaystyle \pi _{r(i+1)}=\{X_{r(i)}\}} . MIMIC models a distribution p t + 1 ( X 1 , … , X N ) = p t ( X r ( N ) ) ∏ i = 1 N − 1 p t ( X r ( i ) | X r ( i + 1 ) ) . {\displaystyle p_{t+1}(X_{1},\dots ,X_{N})=p_{t}(X_{r(N)})\prod _{i=1}^{N-1}p_{t}(X_{r(i)}|X_{r(i+1)}).} New solutions are sampled from the leftmost to the rightmost variable, the first is generated independently and the others according to conditional probabilities. Since the estimated distribution must be recomputed each generation, MIMIC uses concrete populations in the following way P ( t + 1 ) = β μ ∘ α MIMIC ∘ S ( P ( t ) ) . {\displaystyle P(t+1)=\beta _{\mu }\circ \alpha _{\text{MIMIC}}\circ S(P(t)).} === Bivariate marginal distribution algorithm (BMDA) === The BMDA factorizes the joint probability distribution in bivariate distributions. First, a randomly chosen variable is added as a node in a graph, the most dependent variable to one of those in the graph is chosen among those not yet in the graph, this procedure is repeated until no remain
Perceptual robotics
Perceptual robotics is an interdisciplinary science linking Robotics and Neuroscience. It investigates biologically motivated robot control strategies, concentrating on perceptual rather than cognitive processes and thereby sides with J. J. Gibson's view against the Poverty of the stimulus theory. As a working definition, the following quote from Chapter 64 by H. Bülthoff, C. Wallraven and M. Giese from The Springer Handbook of Robotics, edited by Bruno Siciliano and Oussama Khatib, published by Springer in 2007, could be used: In the following we will apply the term Perceptual Robotics to signify the design of robots based on principles that are derived from human perception on all three levels in the sense of Marr. This includes a realization in terms of specific neural circuits as well as the transfer of more abstract biologically-inspired strategies for the solution of relevant computational problems.
WiPay
WiPay is a Caribbean-based payment technology company that specializes in electronic payments for businesses. WiPay was founded in 2016 by Aldwyn Wayne Jr., a Trinidadian businessman and graduate of Georgia Tech Institute. In September 2019, WiPay partnered with MasterCard. As a result, WiPay became the only licensed Payment Facilitator (PAYFAC) on both the MasterCard and Visa networks in the region.
Software requirements
Software requirements for a system are the description of what the system should do, the service or services that it provides and the constraints on its operation. The IEEE Standard Glossary of Software Engineering Terminology defines a requirement as: A condition or capability needed by a user to solve a problem or achieve an objective A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed document A documented representation of a condition or capability as in 1 or 2 The activities related to working with software requirements can broadly be broken down into elicitation, analysis, specification, and management. Note that the wording Software requirements is additionally used in software release notes to explain, which depending on software packages are required for a certain software to be built/installed/used. == Elicitation == Elicitation is the gathering and discovery of requirements from stakeholders and other sources. A variety of techniques can be used such as joint application design (JAD) sessions, interviews, document analysis, focus groups, etc. Elicitation is the first step of requirements development. == Analysis == Analysis is the logical breakdown that proceeds from elicitation. Analysis involves reaching a richer and more precise understanding of each requirement and representing sets of requirements in multiple, complementary ways. Requirements Triage or prioritization of requirements is another activity which often follows analysis. This relates to Agile software development in the planning phase, e.g. by Planning poker, however it might not be the same depending on the context and nature of the project and requirements or product/service that is being built. == Specification == Specification involves representing and storing the collected requirements knowledge in a persistent and well-organized fashion that facilitates effective communication and change management. Use cases, user stories, functional requirements, and visual analysis models are popular choices for requirements specification. == Validation == Validation involves techniques to confirm that the correct set of requirements has been specified to build a solution that satisfies the project's business objectives, and to detect and correct errors in the requirements before implementation. == Management == Requirements change during projects and there are often many of them. Management of this change becomes paramount to ensuring that the correct software is built for the stakeholders. == Tool support for Requirements Engineering == === Tools for Requirements Elicitation, Analysis and Validation === Taking into account that these activities may involve some artifacts such as observation reports (user observation), questionnaires (interviews, surveys and polls), use cases, user stories; activities such as requirement workshops (charrettes), brainstorming, mind mapping, role-playing; and even, prototyping; software products providing some or all of these capabilities can be used to help achieve these tasks. There is at least one author who advocates, explicitly, for mind mapping tools such as FreeMind; and, alternatively, for the use of specification by example tools such as Concordion. Additionally, the ideas and statements resulting from these activities may be gathered and organized with wikis and other collaboration tools such as Trello. The features actually implemented and standards compliance vary from product to product. === Tools for Requirements Specification === A Software requirements specification (SRS) document might be created using general-purpose software like a word processor or one of several specialized tools. Some of these tools can import, edit, export and publish SRS documents. It may help to make SRS documents while following a standardised structure and methodology, such as ISO/IEC/IEEE 29148:2018. Likewise, software may or not use some standard to import or export requirements (such as ReqIF) or not allow these exchanges at all. === Tools for Requirements Document Verification === Tools of this kind verify if there are any errors in a requirements document according to some expected structure or standard. === Tools for Requirements Comparison === Tools of this kind compare two requirement sets according to some expected document structure and standard. === Tools for Requirements Merge and Update === Tools of this kind allow the merging and update of requirement documents. === Tools for Requirements Traceability === Tools of this kind allow tracing requirements to other artifacts such as models and source code (forward traceability) or, to previous ones such as business rules and constraints (backwards traceability). === Tools for Model-Based Software or Systems Requirement Engineering === Model-based systems engineering (MBSE) is the formalised application of modelling to support system requirements, design, analysis, verification and validation activities beginning in the conceptual design phase and continuing throughout development and later lifecycle phases. It is also possible to take a model-based approach for some stages of the requirements engineering and, a more traditional one, for others. Very many combinations might be possible. The level of formality and complexity depends on the underlying methodology involved (for instance, i is much more formal than SysML and, even more formal than UML) === Tools for general Requirements Engineering === Tools in this category may provide some mix of the capabilities mentioned previously and others such as requirement configuration management and collaboration. The features actually implemented and standards compliance vary from product to product. There are even more capable or general tools that support other stages and activities. They are classified as ALM tools.
Physicalization
Physicalization of computer hardware (the opposite of virtualization), is a way to place multiple physical machines in a rack unit. It can be a way to reduce hardware costs, since in some cases, server processors cost more per core than energy efficient laptop processors, which may make up for added cost of board level integration. While Moore's law makes increasing integration less expensive, some jobs require much I/O bandwidth, which may be less expensive to provide using many less-integrated processors. Applications and services that are I/O bound are likely to benefit from such physicalized environments. This ensures that each operating system instance is running on a processor that has its own network interface card, host bus and I/O sub-system unlike in the case of a multi-core servers where a single I/O sub-system is shared between all the cores / VMs.
Google Mobile Services
Google Mobile Services (GMS) is a collection of proprietary applications and application programming interfaces (APIs) services from Google that are typically pre-installed on the majority of Android devices, such as smartphones, tablets, and smart TVs. GMS is not a part of the Android Open Source Project (AOSP), which means an Android manufacturer needs to obtain a license from Google in order to legally pre-install GMS on an Android device. This license is provided by Google without any licensing fees except in the EU. == Core applications == The following are core applications that are part of Google Mobile Services: Google Search Google Chrome YouTube Google Play Google Drive Gmail Google Meet Google Maps Google Photos Google TV YouTube Music === Historically === Google+ Google Hangouts Google Wallet Google Play Magazines Google Play Music Google Play Movies & TV Google Duo == Reception, competitors, and regulators == === FairSearch === Numerous European firms filed a complaint to the European Commission stating that Google had manipulated their power and dominance within the market to push their Services to be used by phone manufacturers. The firms were joined under the name FairSearch, and the main firms included were Microsoft, Expedia, TripAdvisor, Nokia and Oracle. FairSearch's major problem with Google's practices was that they believed Google were forcing phone manufacturers to use their Mobile Services. They claimed Google managed this by asking these manufacturers to sign a contract stating that they must preinstall specific Google Mobile Services, such as Maps, Search and YouTube, in order to get the latest version of Android. Google swiftly responded stating that they "continue to work co-operatively with the European Commission". === Aptoide === The third-party Android app store Aptoide also filed an EU competition complaint against Google once again stating that they are misusing their power within the market. Aptoide alleged that Google was blocking third-party app stores from being on Google Play, as well as blocking Google Chrome from downloading any third-party apps and app stores. As of June 2014, Google had not responded to these allegations. === Abuse of Android dominance === In May 2019, Umar Javeed, Sukarma Thapar, Aaqib Javeed vs. Google LLC & Ors. the Competition Commission of India ordered an antitrust probe against Google for abusing its dominant position with Android to block market rivals. In Prima Facie opinion the commission held that mandatory pre-installation of the entire Google Mobile Services (GMS) suite, under Mobile Application Distribution Agreements (MADA), amounts to the imposition of unfair conditions on the device manufacturers. === EU antitrust ruling === On July 18, 2018, the European Commission fined Google €4.34 billion for breaching EU antitrust rules which resulted in a change of licensing policy for the GMS in the EU. A new paid licensing agreement for smartphones and tablets shipped into the EEA was created. The change is that the GMS is now decoupled from the base Android and will be offered under a separate paid licensing agreement. === Privacy policy === At the same time, Google faced problems with various European data protection agencies, most notably In the United Kingdom and France. The problem they faced was that they had a set of 60 rules merged into one, which allowed Google to "track users more closely". Google once again came out and stated that their new policies still abide by European Union laws. === Android distributions without Google Mobile Services === After surveillance and privacy concerns, several custom android distributions have been implemented, such as GrapheneOS, LineageOS, CalyxOS, iodéOS or /e/OS, and they come either without any GMS installed by default or with microG, that adds a compatibility layer.
Dave's Redistricting
Dave's Redistricting App (DRA) is an online web app originally created by Dave Bradlee that allows anyone to simulate redistricting a U.S. state's congressional and legislative districts. == Purpose == According to Bradlee, the software was designed to "put power in people's hands," and so that they "can see how the process works, so it's a little less mysterious than it was 10 years ago." Bradlee has noticed that many citizens are taking this process seriously and using his app to create legitimate redistricting maps that could be put in place. Some websites have called Bradlee the pioneer and cause of the rise of do-it-yourself redistricting. States such as Montana in 2021 allowed the general population to use it to submit redistricting proposals following the 2020 United States Census. Dave's Redistricting has frequently been mentioned as a resource that can be used to combat gerrymandering, given that the public has free access to it. Political science firms such as FiveThirtyEight have used the website to draw examples of gerrymandered districts, including on their famous Atlas of Redistricting. Dave Bradlee built the first generation of DRA. DRA 2020 is built by a small team of volunteers—Dave Bradlee, Terry Crowley, Alec Ramsay, and David Rinn—all with a shared passion for technology & democracy and all Microsoft veterans. Their mission is to empower civic organizations and citizen activists to advocate for fair congressional and legislative districts and increased transparency in the redistricting process. == Functions == Users can redraw the congressional and state legislative districts for all 50 states, the District of Columbia, and Puerto Rico using a variety of census and election datasets including Cook PVI. Maps can be optimized for different criteria. DRA 2020 added several major features to the first generation app: Sharing & collaborative editing of maps, like Google Docs Multiple statewide elections for all 50 states including the ability to import your own data Comprehensive analytics for evaluating and comparing maps Custom overlays, and Block-level editing DRA remains free to use. == Versions == 2.2: This uses Bing Maps, an outdated software that projects the districts of a single state onto a map of the United States. 2.5: After Bing Maps announced that it would no longer be updating for the foreseen future, the U.S. Map feature was removed. DRA 2020: At the end of 2018, a beta version of 2020 was released. This version that did not require Microsoft Silverlight and could be used in any web browser. DRA 2020 has been under continuous development since and is built using React (JavaScript library), Mapbox, OpenStreetMap, TypeScript, Node.js, Amazon Web Services, as well as many open source components, tools, and icons.