AI Analytics Healthcare

AI Analytics Healthcare — independent reviews, comparisons, pricing and step-by-step guides on Aizhi.

  • Confused deputy problem

    Confused deputy problem

    In information security, a confused deputy is a computer program that is tricked by another program (with fewer privileges or less rights) into misusing its authority on the system. It is a specific type of privilege escalation. The confused deputy problem is often cited as an example of why capability-based security is important. Capability systems protect against the confused deputy problem, whereas access-control list–based systems do not. Such systems can mitigate the confused deputy problem by eliminating ambient authority, allowing programs to act only on resources for which they hold explicit capabilities, whereas access-control list–based systems are more susceptible to it. However, this protection depends on correct implementation; in formally verified capability systems such as seL4, it can be shown that the kernel enforces capability constraints correctly, preventing such behavior at the system level. == Example == In the original example of a confused deputy, there was a compiler program provided on a commercial timesharing service. Users could run the compiler and optionally specify a filename where it would write debugging output, and the compiler would be able to write to that file if the user had permission to write there. The compiler also collected statistics about language feature usage. Those statistics were stored in a file called "(SYSX)STAT", in the directory "SYSX". To make this possible, the compiler program was given permission to write to files in SYSX. But there were other files in SYSX: in particular, the system's billing information was stored in a file "(SYSX)BILL". A user ran the compiler and named "(SYSX)BILL" as the desired debugging output file. This produced a confused deputy problem. The compiler made a request to the operating system to open (SYSX)BILL. Even though the user did not have access to that file, the compiler did, so the open succeeded. The compiler wrote the compilation output to the file (here "(SYSX)BILL") as normal, overwriting it, and the billing information was destroyed. === The confused deputy === In this example, the compiler program is the deputy because it is acting at the request of the user. The program is seen as 'confused' because it was tricked into overwriting the system's billing file. Whenever a program tries to access a file, the operating system needs to know two things: which file the program is asking for, and whether the program has permission to access the file. In the example, the file is designated by its name, “(SYSX)BILL”. The program receives the file name from the user, but does not know whether the user had permission to write the file. When the program opens the file, the system uses the program's permission, not the user's. When the file name was passed from the user to the program, the permission did not go along with it; the permission was increased by the system silently and automatically. It is not essential to the attack that the billing file be designated by a name represented as a string. The essential points are that: the designator for the file does not carry the full authority needed to access the file; the program's own permission to access the file is used implicitly. == Other examples == A cross-site request forgery (CSRF) is an example of a confused deputy attack that uses the web browser to perform sensitive actions against a web application. A common form of this attack occurs when a web application uses a cookie to authenticate all requests transmitted by a browser. Using JavaScript, an attacker can force a browser into transmitting authenticated HTTP requests. The Samy computer worm used cross-site scripting (XSS) to turn the browser's authenticated MySpace session into a confused deputy. Using XSS the worm forced the browser into posting an executable copy of the worm as a MySpace message which was then viewed and executed by friends of the infected user. Clickjacking is an attack where the user acts as the confused deputy. In this attack a user thinks they are harmlessly browsing a website (an attacker-controlled website) but they are in fact tricked into performing sensitive actions on another website. An FTP bounce attack can allow an attacker to connect indirectly to TCP ports to which the attacker's machine has no access, using a remote FTP server as the confused deputy. Another example relates to personal firewall software. It can restrict Internet access for specific applications. Some applications circumvent this by starting a browser with instructions to access a specific URL. The browser has authority to open a network connection, even though the application does not. Firewall software can attempt to address this by prompting the user in cases where one program starts another which then accesses the network. However, the user frequently does not have sufficient information to determine whether such an access is legitimate—false positives are common, and there is a substantial risk that even sophisticated users will become habituated to clicking "OK" to these prompts. Not every program that misuses authority is a confused deputy. Sometimes misuse of authority is simply a result of a program error. The confused deputy problem occurs when the designation of an object is passed from one program to another, and the associated permission changes unintentionally, without any explicit action by either party. It is insidious because neither party did anything explicit to change the authority. Another example is when an administrator authorizes an AI agent to act on their behalf, and that AI subsequently delegates authority to another AI agent neither vetted nor authorized by the original administrator. The unvetted AI can then act without permissions or oversight from the original developer. == Solutions == In some systems it is possible to ask the operating system to open a file using the permissions of another client. This solution has some drawbacks: It requires explicit attention to security by the server. A naive or careless server might not take this extra step. It becomes more difficult to identify the correct permission if the server is in turn the client of another service and wants to pass along access to the file. It requires the client to trust the server to not abuse the borrowed permissions. Note that intersecting the server and client's permissions does not solve the problem either, because the server may then have to be given very wide permissions (all of the time, rather than those needed for a given request) in order to act for arbitrary clients. The simplest way to solve the confused deputy problem is to bundle together the designation of an object and the permission to access that object. This is exactly what a capability is. Using capability security in the compiler example, the client would pass to the server a capability to the output file, such as a file descriptor, rather than the name of the file. Since it lacks a capability to the billing file, it cannot designate that file for output. In the cross-site request forgery example, a URL supplied "cross"-site would include its own authority independent of that of the client of the web browser.

    Read more →
  • Shakey the robot

    Shakey the robot

    Shakey the Robot was the first general-purpose mobile robot able to reason about its own actions. While other robots would have to be instructed on each individual step of completing a larger task, Shakey could analyze commands and break them down into basic chunks by itself. Due to its nature, the project combined research in robotics, computer vision, and natural language processing. Because of this, it was the first project that melded logical reasoning and physical action. Shakey was developed at the Artificial Intelligence Center of Stanford Research Institute (now called SRI International). Some of the most notable results of the project include the A search algorithm, the Hough transform, and the visibility graph method. == History == Shakey was developed from approximately 1966 through 1972 with Charles Rosen, Nils Nilsson and Peter Hart as project managers. Other major contributors included Alfred Brain, Sven Wahlstrom, Bertram Raphael, Richard Duda, Richard Fikes, Thomas Garvey, Helen Chan Wolf and Michael Wilber. The project was funded by the Defense Advanced Research Projects Agency (DARPA) based on a SRI proposal submitted in April 1964 for research in "Intelligent Automata", later "Intelligent Automata to Reconnaissance". It was originally designed to have two retractable arms. Now retired from active duty, Shakey is currently on view in a glass display case at the Computer History Museum in Mountain View, California. The project inspired numerous other robotics projects, most notably the Centibots. == Software == The robot's programming was primarily done in LISP. The Stanford Research Institute Problem Solver (STRIPS) planner it used was conceived as the main planning component for the software it utilized. As the first robot that was a logical, goal-based agent, Shakey experienced a limited world. A version of Shakey's world could contain a number of rooms connected by corridors, with doors and light switches available for the robot to interact with. Shakey had a short list of available actions within its planner. These actions involved traveling from one location to another, turning the light switches on and off, opening and closing the doors, climbing up and down from rigid objects, and pushing movable objects around. The STRIPS automated planner could devise a plan to enact all the available actions, even though Shakey himself did not have the capability to execute all the actions within the plan personally. An example mission for Shakey might be something like, an operator types the command "push the block off the platform" at a computer console. Shakey looks around, identifies a platform with a block on it, and locates a ramp in order to reach the platform. Shakey then pushes the ramp over to the platform, rolls up the ramp onto the platform, and pushes the block off the platform. == Hardware == Physically, the robot was particularly tall, and had an antenna for a radio link, sonar range finders, a television camera, on-board processors, and collision detection sensors ("bump detectors"). The robot's tall stature and tendency to shake resulted in its name: We worked for a month trying to find a good name for it, ranging from Greek names to whatnot, and then one of us said, 'Hey, it shakes like hell and moves around, let’s just call it Shakey.' == Research results == The development of Shakey provided far-reaching impact on the fields of robotics and artificial intelligence, as well as computer science in general. Some of the more notable results include the development of the A search algorithm, which is widely used in pathfinding and graph traversal, the process of plotting an efficiently traversable path between points; the Hough transform, which is a feature extraction technique used in image analysis, computer vision, and digital image processing; and the visibility graph method for finding Euclidean shortest paths among obstacles in the plane. == Media and awards == In 1969 the SRI published "SHAKEY: Experimentation in Robot Learning and Planning", a 24-minute video. The project then received media attention. This included an article in the New York Times on April 10, 1969. In 1970, Life referred to Shakey as the "first electronic person"; and in November 1970 National Geographic Magazine covered Shakey and the future of computers. The Association for the Advancement of Artificial Intelligence's AI Video Competition's awards are named "Shakeys" because of the significant impact of the 1969 video. Shakey was inducted into Carnegie Mellon University's Robot Hall of Fame in 2004 alongside such notables as ASIMO and C-3PO. Shakey has been honored with an IEEE Milestone in Electrical Engineering and Computing. Shakey was showcased in the BBC's Towards Tomorrow: Robot (1967) documentary.

    Read more →
  • Intelligent Robotics Group

    Intelligent Robotics Group

    The Intelligent Robotics Group (IRG) is a research organization within the Intelligent Systems Division at the NASA Ames Research Center in California's Silicon Valley. IRG conducts applied research in the area of robotics and autonomy and is one of the principal organizations at NASA responsible for robotics expertise, along with groups at the Jet Propulsion Laboratory and Johnson Space Center. The group's portfolio includes robotics in support of human exploration, perception and navigation, user interfaces, software architectures, and simulation. IRG developed the Astrobee free-flying robots on the International Space Station and was a primary contributor to the VIPER lunar rover in the areas of flight software, navigation, simulation, and mission operations. IRG has also conducted many robotic field test campaigns in support of spaceflight mission concept developments. These experiences led to the commercialization of the GigaPan system in collaboration with Carnegie Mellon University.

    Read more →
  • Linear belief function

    Linear belief function

    Linear belief functions are an extension of the Dempster–Shafer theory of belief functions to the case when variables of interest are continuous. Examples of such variables include financial asset prices, portfolio performance, and other antecedent and consequent variables. The theory was originally proposed by Arthur P. Dempster in the context of Kalman Filters and later was elaborated, refined, and applied to knowledge representation in artificial intelligence and decision making in finance and accounting by Liping Liu. == Concept == A linear belief function intends to represent our belief regarding the location of the true value as follows: We are certain that the truth is on a so-called certainty hyperplane but we do not know its exact location; along some dimensions of the certainty hyperplane, we believe the true value could be anywhere from –∞ to +∞ and the probability of being at a particular location is described by a normal distribution; along other dimensions, our knowledge is vacuous, i.e., the true value is somewhere from –∞ to +∞ but the associated probability is unknown. A belief function in general is defined by a mass function over a class of focal elements, which may have nonempty intersections. A linear belief function is a special type of belief function in the sense that its focal elements are exclusive, parallel sub-hyperplanes over the certainty hyperplane and its mass function is a normal distribution across the sub-hyperplanes. Based on the above geometrical description, Shafer and Liu propose two mathematical representations of a LBF: a wide-sense inner product and a linear functional in the variable space, and as their duals over a hyperplane in the sample space. Monney proposes still another structure called Gaussian hints. Although these representations are mathematically neat, they tend to be unsuitable for knowledge representation in expert systems. == Knowledge representation == A linear belief function can represent both logical and probabilistic knowledge for three types of variables: deterministic such as an observable or controllable, random whose distribution is normal, and vacuous on which no knowledge bears. Logical knowledge is represented by linear equations, or geometrically, a certainty hyperplane. Probabilistic knowledge is represented by a normal distribution across all parallel focal elements. In general, assume X is a vector of multiple normal variables with mean μ and covariance Σ. Then, the multivariate normal distribution can be equivalently represented as a moment matrix: M ( X ) = ( μ Σ ) . {\displaystyle M(X)=\left({\begin{array}{{20}c}\mu \\\Sigma \end{array}}\right).} If the distribution is non-degenerate, i.e., Σ has a full rank and its inverse exists, the moment matrix can be fully swept: M ( X → ) = ( μ Σ − 1 − Σ − 1 ) {\displaystyle M({\vec {X}})=\left({\begin{array}{{20}c}\mu \Sigma ^{-1}\\-\Sigma ^{-1}\end{array}}\right)} Except for normalization constant, the above equation completely determines the normal density function for X. Therefore, M ( X → ) {\displaystyle M({\vec {X}})} represents the probability distribution of X in the potential form. These two simple matrices allow us to represent three special cases of linear belief functions. First, for an ordinary normal probability distribution M(X) represents it. Second, suppose one makes a direct observation on X and obtains a value μ. In this case, since there is no uncertainty, both variance and covariance vanish, i.e., Σ = 0. Thus, a direct observation can be represented as: M ( X ) = ( μ 0 ) {\displaystyle M(X)=\left({\begin{array}{{20}c}\mu \\0\end{array}}\right)} Third, suppose one is completely ignorant about X. This is a very thorny case in Bayesian statistics since the density function does not exist. By using the fully swept moment matrix, we represent the vacuous linear belief functions as a zero matrix in the swept form follows: M ( X → ) = [ 0 0 ] {\displaystyle M({\vec {X}})=\left[{\begin{array}{{20}c}0\\0\end{array}}\right]} One way to understand the representation is to imagine complete ignorance as the limiting case when the variance of X approaches to ∞, where one can show that Σ−1 = 0 and hence M ( X → ) {\displaystyle M({\vec {X}})} vanishes. However, the above equation is not the same as an improper prior or normal distribution with infinite variance. In fact, it does not correspond to any unique probability distribution. For this reason, a better way is to understand the vacuous linear belief functions as the neutral element for combination (see later). To represent the remaining three special cases, we need the concept of partial sweeping. Unlike a full sweeping, a partial sweeping is a transformation on a subset of variables. Suppose X and Y are two vectors of normal variables with the joint moment matrix: M ( X , Y ) = [ μ 1 Σ 11 Σ 21 μ 2 Σ 12 Σ 22 ] {\displaystyle M(X,Y)=\left[{\begin{array}{{20}c}{\begin{array}{{20}c}\mu _{1}\\\Sigma _{11}\\\Sigma _{21}\end{array}}&{\begin{array}{{20}c}\mu _{2}\\\Sigma _{12}\\\Sigma _{22}\end{array}}\end{array}}\right]} Then M(X, Y) may be partially swept. For example, we can define the partial sweeping on X as follows: M ( X → , Y ) = [ μ 1 ( Σ 11 ) − 1 − ( Σ 11 ) − 1 Σ 21 ( Σ 11 ) − 1 μ 2 − μ 1 ( Σ 11 ) − 1 Σ 12 ( Σ 11 ) − 1 Σ 12 Σ 22 − Σ 21 ( Σ 11 ) − 1 Σ 12 ] {\displaystyle M({\vec {X}},Y)=\left[{\begin{array}{{20}c}{\begin{array}{{20}c}\mu _{1}(\Sigma _{11})^{-1}\\-(\Sigma _{11})^{-1}\\\Sigma _{21}(\Sigma _{11})^{-1}\end{array}}&{\begin{array}{{20}c}\mu _{2}-\mu _{1}(\Sigma _{11})^{-1}\Sigma _{12}\\(\Sigma _{11})^{-1}\Sigma _{12}\\\Sigma _{22}-\Sigma _{21}(\Sigma _{11})^{-1}\Sigma _{12}\end{array}}\end{array}}\right]} If X is one-dimensional, a partial sweeping replaces the variance of X by its negative inverse and multiplies the inverse with other elements. If X is multidimensional, the operation involves the inverse of the covariance matrix of X and other multiplications. A swept matrix obtained from a partial sweeping on a subset of variables can be equivalently obtained by a sequence of partial sweepings on each individual variable in the subset and the order of the sequence does not matter. Similarly, a fully swept matrix is the result of partial sweepings on all variables. We can make two observations. First, after the partial sweeping on X, the mean vector and covariance matrix of X are respectively μ 1 ( Σ 11 ) − 1 {\displaystyle \mu _{1}(\Sigma _{11})^{-1}} and − ( Σ 11 ) − 1 {\displaystyle -(\Sigma _{11})^{-1}} , which are the same as that of a full sweeping of the marginal moment matrix of X. Thus, the elements corresponding to X in the above partial sweeping equation represent the marginal distribution of X in potential form. Second, according to statistics, μ 2 − μ 1 ( Σ 11 ) − 1 Σ 12 {\displaystyle \mu _{2}-\mu _{1}(\Sigma _{11})^{-1}\Sigma _{12}} is the conditional mean of Y given X = 0; Σ 22 − Σ 21 ( Σ 11 ) − 1 Σ 12 {\displaystyle \Sigma _{22}-\Sigma _{21}(\Sigma _{11})^{-1}\Sigma _{12}} is the conditional covariance matrix of Y given X = 0; and ( Σ 11 ) − 1 Σ 12 {\displaystyle (\Sigma _{11})^{-1}\Sigma _{12}} is the slope of the regression model of Y on X. Therefore, the elements corresponding to Y indices and the intersection of X and Y in M ( X → , Y ) {\displaystyle M({\vec {X}},Y)} represents the conditional distribution of Y given X = 0. These semantics render the partial sweeping operation a useful method for manipulating multivariate normal distributions. They also form the basis of the moment matrix representations for the three remaining important cases of linear belief functions, including proper belief functions, linear equations, and linear regression models. === Proper linear belief functions === For variables X and Y, assume there exists a piece of evidence justifying a normal distribution for variables Y while bearing no opinions for variables X. Also, assume that X and Y are not perfectly linearly related, i.e., their correlation is less than 1. This case involves a mix of an ordinary normal distribution for Y and a vacuous belief function for X. Thus, we represent it using a partially swept matrix as follows: M ( X → , Y ) = [ 0 0 0 μ 2 0 Σ 22 ] {\displaystyle M({\vec {X}},Y)=\left[{\begin{array}{{20}c}{\begin{array}{{20}c}0\\0\\0\end{array}}&{\begin{array}{{20}c}\mu _{2}\\0\\\Sigma _{22}\\\end{array}}\end{array}}\right]} This is how we could understand the representation. Since we are ignorant on X, we use its swept form and set μ 1 ( Σ 11 ) − 1 = 0 {\displaystyle \mu _{1}(\Sigma _{11})^{-1}=0} and − ( Σ 11 ) − 1 = 0 {\displaystyle -(\Sigma _{11})^{-1}=0} . Since the correlation between X and Y is less than 1, the regression coefficient of X on Y approaches to 0 when the variance of X approaches to ∞. Therefore, ( Σ 11 ) − 1 Σ 12 = 0 {\displaystyle (\Sigma _{11})^{-1}\Sigma _{12}=0} . Similarly, one can prove that μ 1 ( Σ 11 ) − 1 Σ 12 = 0 {\displaystyle \mu _{1}(\Sigma _{11})^{-1}\Sigma _{12}=0} and Σ 21 ( Σ 11 ) −

    Read more →
  • Dr. Sbaitso

    Dr. Sbaitso

    Dr. Sbaitso ( SPAYT-soh) is an artificial intelligence speech synthesis program released late in 1991 by Creative Labs in Singapore for MS-DOS-based personal computers. The name is an acronym for "SoundBlaster Acting Intelligent Text-to-Speech Operator." == History == Dr. Sbaitso was distributed with various sound cards manufactured by Creative Technology in the early 1990s. The text-to-speech engine used is a version of Monologue, which was developed by First Byte Software. Monologue is a later release of First Byte's "SmoothTalker" software from 1984. The program "conversed" with the user as if it were a psychologist, though most of its responses were along the lines of "WHY DO YOU FEEL THAT WAY?" rather than any sort of complicated interaction. When confronted with a phrase it could not understand, it would often reply with something such as "THAT'S NOT MY PROBLEM." Dr. Sbaitso repeated text out loud that was typed after the word "SAY." Repeated swearing or abusive behavior on the part of the user caused Dr. Sbaitso to "break down" in a "PARITY ERROR" before resetting itself. The same would happen, if the user types "SAY PARITY." The program introduced itself with the following lines: HELLO [UserName], MY NAME IS DOCTOR SBAITSO. I AM HERE TO HELP YOU. SAY WHATEVER IS IN YOUR MIND FREELY, OUR CONVERSATION WILL BE KEPT IN STRICT CONFIDENCE. MEMORY CONTENTS WILL BE WIPED OFF AFTER YOU LEAVE, SO, TELL ME ABOUT YOUR PROBLEMS. The program was designed to showcase the digitized voices the cards were able to produce, though the quality was far from lifelike. Additionally, there was a version of this program for Microsoft Windows through the use of a program called Prody Parrot; this version of the software featured a more detailed graphical user interface. The text-to-speech was also used as the voice of 1st Prize from the Baldi's Basics series, albeit slowed down. == Commands == If the user submits "HELP", a list of commands will appear. If the user then submits "M", more commands will appear. There are three pages of commands in total, with guidance on how to use each of the features.

    Read more →
  • Reification (knowledge representation)

    Reification (knowledge representation)

    Reification in knowledge representation is the process of turning a predicate or statement into an addressable object. Reification allows the representation of assertions so that they can be referred to or qualified by other assertions, i.e., meta-knowledge. The message "John is six feet tall" is an assertion involving truth that commits the speaker to its factuality, whereas the reified statement "Mary reports that John is six feet tall" defers such commitment to Mary. In this way, the statements can be incompatible without creating contradictions in reasoning. For example, the statements "John is six feet tall" and "John is five feet tall" are mutually exclusive (and thus incompatible), but the statements "Mary reports that John is six feet tall" and "Paul reports that John is five feet tall" are not incompatible, as they are both governed by a conclusive rationale that either Mary or Paul is (or both are), in fact, incorrect. In linguistics, reporting, telling, and saying are recognized as verbal processes that project a wording (or locution). If a person says that "Paul told x" and "Mary told y", this person stated only that the telling took place. In this case, the person who made these two statements did not represent a person inconsistently. In addition, if two people are talking to each other, let's say Paul and Mary, and Paul tells Mary "John is five feet tall" and Mary rejects Paul's statement by saying "No, he is actually six feet tall", the socially constructed model of John does not become inconsistent. The reason for that is that statements are to be understood as an attempt to convince the addressee of something (Austin's How to do things with words), alternatively as a request to add some attribute to the model of Paul. The response to a statement can be an acknowledgement, in which case the model is changed, or it can be a statement rejection, in which case the model does not get changed. Finally, the example above for which John is said to be "five feet tall" or "six feet tall" is only incompatible because John can only be a single number of feet tall. If the attribute were a possession as in "he has a dog" or "he also has a cat", a model inconsistency would not happen. In other words, the issue of model inconsistency has to do with our model of the domain element (John) and not with the ascription of different range elements (measurements such as "five feet tall" or "six feet tall").

    Read more →
  • ML.NET

    ML.NET

    ML.NET is a free software machine learning library for the C# and F# programming languages. It also supports Python models when used together with NimbusML. The preview release of ML.NET included transforms for feature engineering like n-gram creation, and learners to handle binary classification, multi-class classification, and regression tasks. Additional ML tasks like anomaly detection and recommendation systems have since been added, and other approaches like deep learning will be included in future versions. == Machine learning == ML.NET brings model-based Machine Learning analytic and prediction capabilities to existing .NET developers. The framework is built upon .NET Core and .NET Standard inheriting the ability to run cross-platform on Linux, Windows and macOS. Although the ML.NET framework is new, its origins began in 2002 as a Microsoft Research project named TMSN (text mining search and navigation) for use internally within Microsoft products. It was later renamed to TLC (the learning code) around 2011. ML.NET was derived from the TLC library and has largely surpassed its parent says Dr. James McCaffrey, Microsoft Research. Developers can train a Machine Learning Model or reuse an existing Model by a 3rd party and run it on any environment offline. This means developers do not need to have a background in Data Science to use the framework. Support for the open-source Open Neural Network Exchange (ONNX) Deep Learning model format was introduced from build 0.3 in ML.NET. The release included other notable enhancements such as Factorization Machines, LightGBM, Ensembles, LightLDA transform and OVA. The ML.NET integration of TensorFlow is enabled from the 0.5 release. Support for x86 & x64 applications was added to build 0.7 including enhanced recommendation capabilities with Matrix Factorization. A full roadmap of planned features have been made available on the official GitHub repo. The first stable 1.0 release of the framework was announced at Build (developer conference) 2019. It included the addition of a Model Builder tool and AutoML (Automated Machine Learning) capabilities. Build 1.3.1 introduced a preview of Deep Neural Network training using C# bindings for Tensorflow and a Database loader which enables model training on databases. The 1.4.0 preview added ML.NET scoring on ARM processors and Deep Neural Network training with GPU's for Windows and Linux. === Performance === Microsoft's paper on machine learning with ML.NET demonstrated it is capable of training sentiment analysis models using large datasets while achieving high accuracy. Its results showed 95% accuracy on Amazon's 9GB review dataset. === Model builder === The ML.NET CLI is a Command-line interface which uses ML.NET AutoML to perform model training and pick the best algorithm for the data. The ML.NET Model Builder preview is an extension for Visual Studio that uses ML.NET CLI and ML.NET AutoML to output the best ML.NET Model using a GUI. === Model explainability === AI fairness and explainability has been an area of debate for AI Ethicists in recent years. A major issue for Machine Learning applications is the black box effect where end users and the developers of an application are unsure of how an algorithm came to a decision or whether the dataset contains bias. Build 0.8 included model explainability API's that had been used internally in Microsoft. It added the capability to understand the feature importance of models with the addition of 'Overall Feature Importance' and 'Generalized Additive Models'. When there are several variables that contribute to the overall score, it is possible to see a breakdown of each variable and which features had the most impact on the final score. The official documentation demonstrates that the scoring metrics can be output for debugging purposes. During training & debugging of a model, developers can preview and inspect live filtered data. This is possible using the Visual Studio DataView tools. === Infer.NET === Microsoft Research announced the popular Infer.NET model-based machine learning framework used for research in academic institutions since 2008 has been released open source and is now part of the ML.NET framework. The Infer.NET framework utilises probabilistic programming to describe probabilistic models which has the added advantage of interpretability. The Infer.NET namespace has since been changed to Microsoft.ML.Probabilistic consistent with ML.NET namespaces. === NimbusML Python support === Microsoft acknowledged that the Python programming language is popular with Data Scientists, so it has introduced NimbusML the experimental Python bindings for ML.NET. This enables users to train and use machine learning models in Python. It was made open source similar to Infer.NET. === Machine learning in the browser === ML.NET allows users to export trained models to the Open Neural Network Exchange (ONNX) format. This establishes an opportunity to use models in different environments that don't use ML.NET. It would be possible to run these models in the client side of a browser using ONNX.js, a JavaScript client-side framework for deep learning models created in the Onnx format. === AI School Machine Learning Course === Along with the rollout of the ML.NET preview, Microsoft rolled out free AI tutorials and courses to help developers understand techniques needed to work with the framework.

    Read more →
  • Computer Power and Human Reason

    Computer Power and Human Reason

    Computer Power and Human Reason: From Judgment to Calculation is a 1976 nonfiction book by German-American computer scientist Joseph Weizenbaum in which he contends that while artificial intelligence may be possible, we should never allow computers to make important decisions, as they will always lack human qualities such as compassion and wisdom. == Background == Before writing Computer Power and Human Reason, Weizenbaum had garnered significant attention for creating the ELIZA program, an early milestone in conversational computing. His firsthand observation of people attributing human-like qualities to a simple program prompted him to reflect more deeply on society's readiness to entrust moral and ethical considerations to machines. == Reception and legacy == Computer Power and Human Reason sparked scholarly debate on the acceptable scope of AI applications, particularly in fields where human welfare and ethical considerations are paramount. Early academic reviews highlighted that Weizenbaum's stance pushed readers to recognize that even as computers grow more capable, they lack the intrinsic moral compass and empathy required for certain kinds of judgment. The book caused disagreement with, and separation from, other members of the artificial intelligence research community, a status the author later said he'd come to take pride in.

    Read more →
  • Cinema 4D

    Cinema 4D

    Cinema 4D is a 3D software suite developed by the German company Maxon. == Overview == As of R21, only a single version of Cinema 4D is available. It replaces all previous variants, including BodyPaint 3D, and includes all features of the past 'Studio' variant. With R21, all binaries were unified. There is no technical difference between commercial, educational, or demo versions. The difference is now only in licensing. 2014 saw the release of Cinema 4D Lite, which came packaged with Adobe After Effects Creative Cloud 2014. "Lite" acts as an introductory version, with many features withheld. This is part of a partnership between the two companies, where a Maxon-produced plug-in, called Cineware, allows any variant to create a seamless workflow with After Effects. The "Lite" variant is dependent on After Effects CC, needing the latter application running to launch, and is only sold as a package component included with After Effects CC through Adobe. Initially, Cinema 4D was developed for Amiga computers in the early 1990s, and the first three versions of the program were available exclusively for that platform. With v4, however, Maxon began to develop the application for Windows and Macintosh computers as well, citing the wish to reach a wider audience and the growing instability of the Amiga market following Commodore's bankruptcy. It was also released for BeOS. On Linux, Cinema 4D is available as a commandline rendering version. == Modules and older variants == From R12 to R20, Cinema 4D was available in four variants. A core Cinema 4D 'Prime' application, a 'Broadcast' version with additional motion-graphics features, 'Visualize,' which adds functions for architectural design and 'Studio,' which includes all modules. From Release 8 until Release 11.5, Cinema 4D had a modular approach to the application, with the ability to expand upon the core application with various modules. This ended with Release 12, though the functionality of these modules remains in the different flavors of Cinema 4D (Prime, Broadcast, Visualize, Studio) The old modules were: Advanced Render (global illumination/HDRI, caustics, ambient occlusion and sky simulation) BodyPaint 3D (direct painting on UVW meshes; now included in the core. In essence Cinema 4D Core/Prime and the BodyPaint 3D products are identical. The only difference between the two is the splash screen that is shown at startup and the default user interface.) Dynamics (for simulating soft body and rigid body dynamics) Hair (simulates hair, fur, grass, etc.) MOCCA (character animation and cloth simulation) MoGraph (Motion Graphics procedural modelling and animation toolset) NET Render (to render animations over a TCP/IP network in render farms) PyroCluster (simulation of smoke and fire effects) Prime (the core application) Broadcast (adds MoGraph2) Visualize (adds Virtual Walkthrough, Advanced Render, Sky, Sketch and Toon, data exchange, camera matching) Studio (the complete package) == Version history == == Use in industry == A number of films and related works have been modeled and rendered in Cinema 4D, including: == Cinebench == Cinebench is a cross-platform test suite which tests a computer's hardware capabilities. It can be used as a test for Cinema 4D's 3D modeling, animation, motion graphic and rendering performance on multiple CPU cores. The program "target[s] a certain niche and [is] better suited for high-end desktop and workstation platforms". Cinebench is commonly used to demonstrate hardware capabilities at tech shows to show a CPU performance, especially by tech YouTubers and review sites.

    Read more →
  • Darkforest

    Darkforest

    Darkforest is a computer go program developed by Meta Platforms, based on deep learning techniques using a convolutional neural network. Its updated version Darkfores2 combines the techniques of its predecessor with Monte Carlo tree search. The MCTS effectively takes tree search methods commonly seen in computer chess programs and randomizes them. With the update, the system is known as Darkfmcts3. Darkforest is of similar strength to programs like CrazyStone and Zen. It has been tested against a professional human player at the 2016 UEC cup. Google's AlphaGo program won against a professional player in October 2015 using a similar combination of techniques. Darkforest is named after Liu Cixin's science fiction novel The Dark Forest. == Background == Competing with top human players in the ancient game of Go has been a long-term goal of artificial intelligence. Go's high branching factor makes traditional search techniques ineffective, even on cutting-edge hardware, and Go's evaluation function could change drastically with one stone change. However, by using a Deep Convolutional Neural Network designed for long-term predictions, Darkforest has been able to substantially improve the win rate for bots over more traditional Monte Carlo Tree Search based approaches. === Matches === Against human players, Darkfores2 achieves a stable 3d ranking on KGS Go Server, which roughly corresponds to an advanced amateur human player. However, after adding Monte Carlo Tree Search to Darkfores2 to create a much stronger player named darkfmcts3, it can achieve a 5d ranking on the KGS Go Server. ==== Against other AI ==== darkfmcts3 is on par with state-of-the-art Go AIs such as Zen, DolBaram and Crazy Stone, but lags behind AlphaGo. It won 3rd place in January 2016 KGS Bot Tournament against other Go AIs. === News coverage === After Google's AlphaGo won against Fan Hui in 2015, Facebook made its AI's hardware designs public, alongside releasing the code behind DarkForest as open-source, in addition to heavy recruiting to strengthen its team of AI engineers. == Style of play == Darkforest uses a neural network to sort through the 10100 board positions, and find the most powerful next move. However, neural networks alone cannot match the level of good amateur players or the best search-based Go engines, and so Darkfores2 combines the neural network approach with a search-based machine. A database of 250,000 real Go games were used in the development of Darkforest, with 220,000 used as a training set and the rest used to test the neural network's ability to predict the next moves played in the real games. This allows Darkforest to accurately evaluate the global state of the board, but local tactics were still poor. Search-based engines have poor global evaluation, but are good at local tactics. Combining these two approaches is difficult because search-based engines work much faster than neural networks, a problem which was solved in Darkfores2 by running the processes in parallel with frequent communication between the two. === Conventional strategies === Go is generally played by analyzing the position of the stones on the board. Various advanced players have described it as playing in some part subconsciously. Unlike chess and checkers, where AI players can simply look further forward at moves than human players, but with each round of Go having on average 250 possible moves, that approach is ineffective. Instead, neural networks copy human play by training the AI systems on images of successful moves, the AI can effectively learn how to interpret how the board looks, as many grandmasters do. In November 2015, Facebook demonstrated the combination of MCTS with neural networks, which played with a style that "felt human". === Flaws === It has been noted that Darkforest still has flaws in its playstyle. The bot sometimes plays tenuki ("move elsewhere") pointlessly when local powerful moves are required. When the bot is losing, it shows the typical behavior of MCTS, it plays bad moves and loses more. The Facebook AI team has acknowledged these as areas of future improvement. == Program architecture == The family of Darkforest computer go programs is based on convolution neural networks. The most recent advances in Darkfmcts3 combined convolutional neural networks with more traditional Monte Carlo tree search. Darkfmcts3 is the most advanced version of Darkforest, which combines Facebook's most advanced convolutional neural network architecture from Darkfores2 with a Monte Carlo tree search. Darkfmcts3 relies on a convolution neural networks that predicts the next k moves based on the current state of play. It treats the board as a 19x19 image with multiple channels. Each channel represents a different aspect of board information based upon the specific style of play. For standard and extended play, there are 21 and 25 different channels, respectively. In standard play, each players liberties are represented as six binary channels or planes. The respective plane is true if the player one, two, or three or more liberties available. Ko (i.e. illegal moves) is represented as one binary plane. Stone placement for each opponent and empty board positions are represented as three binary planes, and the duration since a stone has been placed is represented as real numbers on two planes, one for each player. Lastly, the opponents rank is represented by nine binary planes, where if all are true, the player is a 9d level, if 8 are true, an 8d level, and so forth. Extended play additionally considers the border (binary plane that is true at the border), position mask (represented as distance from the board center, i.e. x ( − 0.5 ∗ d i s t a n c e 2 ) {\displaystyle x^{(-0.5distance^{2})}} , where x {\displaystyle x} is a real number at a position), and each player's territory (binary, based on which player a location is closer to). Darkfmct3 uses a 12-layer full convolutional network with a width of 384 nodes without weight sharing or pooling. Each convolutional layer is followed by a rectified linear unit, a popular activation function for deep neural networks. A key innovation of Darkfmct3 compared to previous approaches is that it uses only one softmax function to predict the next move, which enables the approach to reduce the overall number of parameters. Darkfmct3 was trained against 300 random selected games from an empirical dataset representing different game stages. The learning rate was determined by vanilla stochastic gradient descent. Darkfmct3 synchronously couples a convolutional neural network with a Monte Carlo tree search. Since the convolutional neural network is computationally taxing, the Monte Carlo tree search focuses computation on the more likely game play trajectories. By running the neural network synchronously with the Monte Carlo tree search, it is possible to guarantee that each node is expanded by the moves predicted by the neural network. == Comparison with other systems == Darkfores2 beats Darkforest, its neural network-only predecessor, around 90% of the time, and Pachi, one of the best search-based engines, around 95% of the time. On the Kyu rating system, Darkforest holds a 1-2d level. Darkfores2 achieves a stable 3d level on KGS Go Server as a ranked bot. With the added Monte Carlo tree search, Darkfmcts3 with 5,000 rollouts beats Pachi with 10k rollouts in all 250 games; with 75k rollouts it achieves a stable 5d level in KGS server, on par with state-of-the-art Go AIs (e.g., Zen, DolBaram, CrazyStone); with 110k rollouts, it won the 3rd place in January KGS Go Tournament.

    Read more →
  • Unified Modeling Language

    Unified Modeling Language

    The Unified Modeling Language (UML) is a general-purpose, object-oriented, visual modeling language that provides a way to visualize the architecture and design of a system, similar to the function of a blueprint. UML defines notation for many types of diagrams which focus on aspects such as behavior, interaction, and structure. UML is both a formal metamodel and a collection of graphical templates. The metamodel defines the elements in an object-oriented model such as classes and properties. It is essentially the same thing as the metamodel in object-oriented programming (OOP), however for OOP, the metamodel is primarily used at run time to dynamically inspect and modify an application object model. The UML metamodel provides a mathematical, formal foundation for the graphic views used in the modeling language to describe an emerging system. UML was created in an attempt to define a standard language for object-oriented programming at the OOPSLA '95 Conference. Originally, Grady Booch and James Rumbaugh merged their models into a unified model. This was followed by Booch's company Rational Software purchasing Ivar Jacobson's Objectory company and merging their model into the UML. At the time Rational and Objectory were two of the dominant players in the small world of independent vendors of object-oriented tools and methods. The Object Management Group (OMG) then took ownership of UML. The creation of UML was motivated by the desire to standardize the disparate nature of notational systems and approaches to software design at the time. In 1997, UML was adopted as a standard by the Object Management Group (OMG) and has been managed by this organization ever since. In 2005, UML was also published by the International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC) as the ISO/IEC 19501 standard. Since then the standard has been periodically revised to cover the latest revision of UML. Most developers do not use UML per se, but instead produce more informal diagrams, often hand-drawn. These diagrams, however, often include elements from UML. == Use == UML is primarily used for software development (in any industry or domain) but also used outside elsewhere including business processes, system functions, database schemas, workflow in the legal systems, medical electronics, Health care systems, and hardware design.. The UML is used by the OMG itself to define other OMG products such as the Unified Architecture Framework (UAF) and the Systems Modelling Language (SysML) v1. UML is designed for use with many object-oriented software development methods, both today and for the methods when it was first developed – including OMT, Booch method, Objectory, and especially RUP, which it was originally intended to be used with when work began at Rational Software. Although originally intended for object-oriented design documentation, UML has been used effectively in other contexts such as modeling business process. As UML is not inherently linked to a particular programming language, it can be used for modeling a system independent of language. Some UML tools generate source code from a UML model. === Elements === UML diagrams support visualizing system aspects like: Use case diagram for specifying user interactions with systems Class diagram for specifying structures, including data structures Activity diagram for specifying business process workflows Component diagram for specifying how components interface with other components Deployment diagram for specifying how components are deployed and executed on computational nodes In addition to syntactical (notational) elements with well-defined semantics, UML diagrams also allow for free-form comments (notes) that explain aspects such as usage, constraints, and intents. === Sharing === UML models can be exchanged among UML tools via the XML Metadata Interchange (XMI) format. === Cardinality notation === As with database Chen, Bachman, and ISO ER diagrams, class models are specified to use "look-across" cardinalities, even though several authors (Merise, Elmasri & Navathe, amongst others) prefer same-side or "look-here" for roles and both minimum and maximum cardinalities. Recent researchers (Feinerer and Dullea et al.) have shown that the "look-across" technique used by UML and ER diagrams is less effective and less coherent when applied to n-ary relationships of order strictly greater than 2. Feinerer says: "Problems arise if we operate under the look-across semantics as used for UML associations. Hartmann investigates this situation and shows how and why different transformations fail.", and: "As we will see on the next few pages, the look-across interpretation introduces several difficulties which prevent the extension of simple mechanisms from binary to n-ary associations." === Artifacts === An artifact is the "specification of a physical piece of information that is used or produced by a software development process, or by deployment and operation of a system" including models, source code, scripts, executables, tables in database systems, development deliverables, a design documents, and email messages. An artifact is the physical entity that is deployed to a node. Other UML elements such as classes and components are first manifest into artifacts and instances of these artifacts are then deployed. Artifacts can be composed of other artifacts. === Metamodeling === The OMG developed a metamodeling architecture to define UML, called the Meta-Object Facility (MOF). MOF is designed as a four-layered architecture, as shown in the image at right. It provides a meta-meta model at the top, called the M3 layer. This M3-model is the language used by Meta-Object Facility to build metamodels, called M2-models. The most prominent example of a Layer 2 Meta-Object Facility model is the UML metamodel, which describes UML itself. These M2-models describe elements of the M1-layer, and thus M1-models. These would be, for example, models written in UML. The last layer is the M0-layer or data layer. It is used to describe runtime instances of the system. The metamodel can be extended using a mechanism called stereotyping. This has been criticized as being insufficient/untenable by Brian Henderson-Sellers and Cesar Gonzalez-Perez in "Uses and Abuses of the Stereotype Mechanism in UML 1.x and 2.0". == Diagrams == UML 2 defines many types of diagrams – shown as a taxonomy in the image. === Structure diagrams === Structure diagrams emphasize the structure of the system – using objects, classifiers, relationships, attributes and operations. They are used to document software architecture. Class diagram – Describes the structure of a class Component diagram – Describes how a software system is split into components and dependencies between the components Composite structure diagram Deployment diagram Object diagram Package diagram Profile diagram === Behavior diagrams === Behavior diagrams emphasize the behavior of a system by showing collaborations among objects and changes to the internal states of objects. They are used to describe the functionality of a system. Activity diagram – Describes the business and operational activities of components State machine diagram Use case diagram – Depicts of a user's interaction with a system === Interaction diagrams === Interaction diagrams, a subset of behavior diagrams, emphasize the flow of control and data between components of a system. Communication diagram – shows communication between components Interaction overview diagram Sequence diagram – shows interactions arranged in time sequence; can be drawn via tools such as Lucidchart and Draw.io Timing diagram – focuses on timing constraints === Examples === == Adoption == In 2013, UML had been marketed by OMG for many contexts, but aimed primarily at software development with limited success. It has been treated, at times, as a design silver bullet, which leads to problems. UML misuse includes overuse (designing every part of the system with it, which is unnecessary) and assuming that novices can design with it. It is considered a large language, with many constructs. Some people (including Jacobson) feel that UML's size hinders learning and therefore uptake. Visual Studio removed support for UML in 2016 due to lack of use. == History == UML has evolved since the second half of the 1990s and has its roots in the object-oriented programming methods developed in the late 1980s and early 1990s. The image shows a timeline of the history of UML and other object-oriented modeling methods and notation. === Origin === Rational Software hired James Rumbaugh from General Electric in 1994 and after that, the company became the source for two of the most popular object-oriented modeling approaches of the day: Rumbaugh's object-modeling technique (OMT) and Grady Booch's method. They were soon assisted in their efforts by Ivar Jacobson, the creator of the object-oriented software engineeri

    Read more →
  • Learning Applied to Ground Vehicles

    Learning Applied to Ground Vehicles

    The Learning Applied to Ground Vehicles (LAGR) program, which ran from 2004 until 2008, had the goal of accelerating progress in autonomous, perception-based, off-road navigation in robotic unmanned ground vehicles (UGVs). LAGR was funded by DARPA, a research agency of the United States Department of Defense. == History and background == While mobile robots had been in existence since the 1960s, (e.g. Shakey), progress in creating robots that could navigate on their own, outdoors, off-road, on irregular, obstacle-rich terrain had been slow. In fact, no clear metrics were in place to measure progress. A baseline understanding of off-road capabilities began to emerge with the DARPA PerceptOR program in which independent research teams fielded robotic vehicles in unrehearsed Government tests that measured average speed and number of required operator interventions over a fixed course over widely spaced waypoints. These tests exposed the extreme challenges of off-road navigation. While the PerceptOR vehicles were equipped with sensors and algorithms that were state-of-the-art for the beginning of the 21st century, the limited range of their perception technology caused them to become trapped in natural cul-de-sacs. Furthermore, their reliance on pre-scripted behaviors did not allow them to adapt to unexpected circumstances. The overall result was that except for essentially open terrain with minimal obstacles, or along dirt roads, the PerceptOR vehicles were unable navigate without numerous, repeated operator intervention. The LAGR program was designed to build on the methodology started in PerceptOR while seeking to overcome the technical challenges exposed by the PerceptOR tests. == LAGR goals == The principal goal of LAGR was to accelerate progress in off navigation of UGVs. Additional, synergistic goals included (1) establishing benchmarking methodology for measuring progress for autonomous robots operating in unstructured environments, (2) advancing machine vision and thus enabling long-range perception, and (3) increasing the number of institutions and individuals who were able to contribute to forefront UGV research. == Structure and rationale of the LAGR program == The LAGR program was designed to focus on developing new science for robot perception and control rather than on new hardware. Thus, it was decided to create a fleet of identical, relatively simple robots that would be supplied to the LAGR researchers, who were members of competitive teams, freeing them to concentrate on algorithm development. The teams were each given two robots of the standard design. They developed new software on these robots, and then sent the code to a government test team that then tested that code on Government robots at various test courses. These courses were located throughout the US and were not previously known to the teams. In this way, the code from all teams could be tested in essentially identical circumstances. After an initial startup period, the code development/test cycle was repeated about once every month. The standard robot was designed and built by the Carnegie Mellon University National Robotics Engineering Center (CMU NREC). The vehicles’ computers were preloaded with a modular “Baseline” perception and navigation system that was essentially the same system that CMU NREC had created for the PerceptOR program and was considered to represent the state-of-the-art at the inception of LAGR. The modular nature of the Baseline system allowed the researchers to replace parts of the Baseline code with their own modules and still have a complete working system without having to create an entire navigation system from scratch. Thus, for example, they were able to compare the performance of their own obstacle detection module with that of the Baseline code, while holding everything else fixed. The Baseline code also served as a fixed reference – in any environment and at any time in the program, teams’ code could be compared to the Baseline code. This rapid cycle gave the Government team and the performer teams quick feedback and allowed the Government team to design test courses that challenged the performers in specific perception tasks and whose difficulty was likely to challenge, but not overwhelm, the performers’ current capabilities. Teams were not required to submit new code for every test, but usually did. Despite this leeway, some teams found the rapid test cycle distracting to their long term progress and would have preferred a longer interval between tests. === Phase II === To advance to Phase II, each team had to modify the Baseline code so that on the final 3 tests of Phase I of the government tests, robots running the team's code averaged at least 10% faster than a vehicle running the original Baseline code. This rather modest “Go/ No Go” metric was chosen to allow teams to choose risky, but promising approaches that might not be fully developed in the first 18 months of the program. All 8 teams achieved this metric, with some scoring more twice the speed of the Baseline on the later tests which was the objective for Phase II. Note that the Phase I Go / No Go metric was such that teams were not in completion with each other for a limited number of slots on Phase II: any number of teams, from eight to zero could make the grade. This strategy by DARPA was to designed to encourage cooperation and even code sharing among the teams. == The LAGR teams == Eight teams were selected as performers in Phase I, the first 18 months of LAGR. The teams were from Applied Perception (Principal Investigator [PI] Mark Ollis), Georgia Tech (PI Tucker Balch), Jet Propulsion Laboratory (PI Larry Matthies), Net-Scale Technologies (PI Urs Muller), NIST (PI James Albus), Stanford University (PI Sebastian Thrun), SRI International (PI Robert Bolles), and University of Pennsylvania (PI Daniel Lee). The Stanford team resigned at the end of Phase I to focus its efforts on the DARPA Grand Challenge; it was replaced by a team from the University of Colorado, Boulder (PI Greg Grudic). Also in Phase II, the NIST team suspended its participation in the competition and instead concentrated on assembling the best software elements from each team into a single system. Roger Bostelman became PI of that effort. == The LAGR vehicle == The LAGR vehicle, which was about the size of a supermarket shopping cart, was designed to be simple to control. (A companion DARPA program, Learning Locomotion, addressed complex motor control.) It was battery powered and had two independently driven wheelchair motors in the front, and two caster wheels in the rear. When the front wheels were rotated in the same direction the robot was driven either forward or reverse. When these wheels were driven in opposite directions, the robot turned. The ~ $30,000 cost of the LAGR vehicle meant that a fleet could be built and distributed to a number of teams expanding on the field of researchers who had traditionally participated in DARPA robotics programs. The vehicle's top speed of about 3 miles/ hour and relatively modest weight of ~100 kg meant that it posed a much reduced safety hazard compared to vehicles used in previous programs in unmanned ground vehicles and thus further reduced the budget required for each team to manage its robot. Nevertheless, the LAGR vehicles were sophisticated machines. Their sensor suite included 2 pairs of stereo cameras, an accelerometer, a bumper sensor, wheel encoders, and a GPS. The vehicle also had three computers that were user-programmable. == Scientific results == A cornerstone of the program was incorporation of learned behaviors in the robots. In addition, the program used passive optical systems to accomplish long-range scene analysis. The difficulty of testing UGV navigation in unstructured, off-road environments made accurate, objective measurement of progress a challenging task. While no absolute measure of performance had been defined in LAGR, the relative comparison of a team's code to that of the Baseline code on a given course demonstrated whether progress was being made in that environment. By the conclusion of the program, testing showed that many of the performers had attained leaps in performance. In particular, average autonomous speeds were increased by factor of 3 and useful visual perception was extended to ranges as far as 100 meters. While LAGR did succeed in extending the useful range of visual perception, this was primarily done by either pixel or patch-based color or texture analysis. Object recognition was not directly addressed. Even though the LAGR vehicle had a WAAS GPS, its position was never determined down to the width of the vehicle, so it was hard for the systems to re-use obstacle maps of areas the robots had previously traversed since the GPS continually drifted. The drift was especially severe if there was a forest canopy. A few teams developed visual odometry algorithms that essentially eliminated this drift.

    Read more →
  • SciPy

    SciPy

    SciPy (pronounced "sigh pie") is a free and open-source Python library used for scientific computing and technical computing. SciPy contains modules for optimization, linear algebra, integration, interpolation, special functions, fast Fourier transform, signal and image processing, ordinary differential equation solvers and other tasks common in science and engineering. SciPy is also a family of conferences for users and developers of these tools: SciPy (in the United States), EuroSciPy (in Europe) and SciPy.in (in India). Enthought originated the SciPy conference in the United States and continues to sponsor many of the international conferences as well as host the SciPy website. The SciPy library is currently distributed under the BSD license, and its development is sponsored and supported by an open community of developers. It is also supported by NumFOCUS, a community foundation for supporting reproducible and accessible science. == Components == The SciPy package is at the core of Python's scientific computing capabilities. Available sub-packages include: cluster: hierarchical clustering, vector quantization, K-means constants: physical constants and conversion factors datasets: various example datasets for demonstrating image and data processing differentiate: numerical differentiation for first and second derivatives fft: Discrete Fourier Transform algorithms fftpack: Legacy interface for Discrete Fourier Transforms integrate: numerical integration routines interpolate: interpolation tools io: data input and output, including support for MATLAB and Matrix Market files linalg: linear algebra routines ndimage: various functions for multi-dimensional image processing odr: orthogonal distance regression classes and algorithms optimize: optimization algorithms including linear programming and a variety of numerical nonlinear programming optimizers signal: signal processing tools sparse: sparse matrices and related algorithms spatial: algorithms for spatial structures such as k-d trees, nearest neighbors, convex hulls, etc. special: special functions stats: statistical functions == Data structures == The basic data structure used by SciPy is a multidimensional array provided by the NumPy module. NumPy provides some functions for linear algebra, Fourier transforms, and random number generation, but not with the generality of the equivalent functions in SciPy. NumPy can also be used as an efficient multidimensional container of data with arbitrary datatypes. This allows NumPy to seamlessly and speedily integrate with a wide variety of databases. Older versions of SciPy used Numeric as an array type, which is now deprecated in favor of the newer NumPy array code. == History == In the 1990s, Python was extended to include an array type for numerical computing called Numeric. (This package was eventually replaced by NumPy, which was written by Travis Oliphant in 2006 as a blending of Numeric and Numarray, with Numarray itself being started in 2001.) As of 2000, there was a growing number of extension modules and increasing interest in creating a complete environment for scientific and technical computing. In 2001, Travis Oliphant, Eric Jones, and Pearu Peterson merged code they had written and called the resulting package SciPy. The newly created package provided a standard collection of common numerical operations on top of the Numeric array data structure. Shortly thereafter, Fernando Pérez released IPython, an enhanced interactive shell widely used in the technical computing community, and John Hunter released the first version of Matplotlib, the 2D plotting library for technical computing. Since then the SciPy environment has continued to grow with more packages and tools for technical computing. == Scientific Python versus ScientificPython == In the scientific literature, SciPy is occasionally referred to as "Scientific Python (SciPy)". This is incorrect: the official name of the project is just "SciPy". Furthermore, expanding "SciPy" as "Scientific Python" may cause confusion with "ScientificPython", a project led by Konrad Hinsen of Orléans University that was active between 1995 and 2014. "Scientific Python" is also used for the related ecosystem of tools.

    Read more →
  • Pax Silica

    Pax Silica

    Pax Silica is a United States-led international initiative focused on strengthening and coordinating "trusted" supply chains for advanced technologies—especially semiconductors, artificial intelligence (AI) infrastructure, critical minerals, advanced manufacturing, logistics, and associated energy and data infrastructure. The initiative is coordinated by the US Department of State and was launched in December 2025 alongside the signing of the non-binding Pax Silica Declaration by an initial group of partner countries. The initiative describes itself as a "positive-sum" partnership intended to reduce "coercive dependencies" and improve resilience across the full technology stack, from mineral extraction and processing through chip manufacturing and computing infrastructure. US officials described Pax Silica as a framework for coordinating flagship projects and policy alignment across partner countries, including supply-chain mapping, investment and co-investment initiatives, and protection of critical infrastructure and sensitive technologies. Reuters reported discussions of projects linked to trade and logistics routes and an industrial park initiative in Israel. Gulf countries, such as the UAE and Qatar, are betting on attracting AI companies with cheap energy. Moreover, the UAE's potential to invest in Pax Silica's activities has been noted as a fundamental asset for the initiative. In early 2026, the U.S. announced plans to contribute $250M toward an investmest consortium that's intended to strengthen energy and critical mineral supply chains. == Launch and background == During the 2020s, governments increasingly treated supply-chain resilience in semiconductors, critical minerals, and AI-related computing infrastructure as a national-security priority, amid export controls, industrial policy measures, and geopolitical competition over the technologies underpinning advanced manufacturing and AI. Pax Silica was presented by US officials as an economic-security framework aimed at aligning policies and investment among "trusted partners" that host major technology firms and key industrial capacity. Pacific Forum's analyst Akhil Ramesh, writing for the National Interest magazine, described the initiative as understanding that: "economic security today is inseparable from control over energy, critical minerals, high-end manufacturing, and advanced models." On December 11, 2025, the US Department of State announced the inaugural Pax Silica Summit and a planned signing of the Pax Silica Declaration, describing Pax Silica as the Department's flagship effort on AI and supply-chain security. The initial summit was held in Washington, D.C. on December 12, 2025. The State Department fact sheet described cooperation areas including connectivity and data infrastructure, compute and semiconductors, advanced manufacturing, logistics, mineral refining and processing, and energy. == Membership == Pax Silica participation has been discussed in terms of (1) countries that have signed the declaration and (2) countries invited to summit discussions or publicly reported as prospective signatories but which had not (as of mid-January 2026) signed the declaration. === Countries that signed the Pax Silica Declaration === Seven countries signed the declaration at the December 12, 2025, summit in Washington, D.C.: Australia Israel Japan South Korea Singapore United Kingdom United States Some countries who attended the initial conversations did not immediately sign, while additional countries were invited to join after the discussions concluded. The following are the later signatory countries on the declaration: Greece Netherlands (joined December 17, 2025; "non-signing partner") Qatar (joined January 13, 2026) United Arab Emirates (joined January 14, 2026) India (joined February 20, 2026) Sweden (signed March 17, 2026) Finland (signed April 16, 2026) Philippines (signed April 17, 2026) Norway (signed May 6, 2026) === Countries invited / participating, but not yet signed === At launch, US materials and contemporaneous reporting described additional invited participants and observers, including: Canada – observer/participant in related discussions, per US briefing materials; not listed among signatories. Taiwan – participated in summit sessions according to a State Department briefing; not listed among signatories. The Organisation for Economic Co-operation and Development (OECD) and European Union were also noted by US officials as present in an observer capacity, but are not countries.

    Read more →
  • Minimum information standard

    Minimum information standard

    Minimum information standards are sets of guidelines and formats for reporting data derived by specific high-throughput methods. Their purpose is to ensure the data generated by these methods can be easily verified, analysed and interpreted by the wider scientific community. Ultimately, they facilitate the transfer of data from journal articles (unstructured data) into databases (structured data) in a form that enables data to be mined across multiple data sets. Minimal information standards are available for a vast variety of experiment types including microarray (MIAME), RNAseq (MINSEQE), metabolomics (MSI) and proteomics (MIAPE). Minimum information standards typically have two parts. Firstly, there is a set of reporting requirements – typically presented as a table or a checklist. Secondly, there is a data format. Information about an experiment needs to be converted into the appropriate data format for it to be submitted to the relevant database. In the case of MIAME, the data format is provided in spreadsheet format (MAGE-TAB). Some of the communities that maintain minimum information standards also provide tools to help experimental researchers to annotate their data. == MI Standards == The individual minimum information standards are brought by the communities of cross-disciplinary specialists focused on the problematic of the specific method used in experimental biology. The standards then provide specifications what information about the experiments (metadata) is crucial and important to be reported together with the resultant data to make it comprehensive. The need for this standardization is largely driven by the development of high-throughput experimental methods that provide tremendous amounts of data. The development of minimum information standards of different methods is since 2008 being harmonized by "Minimum Information about a Biomedical or Biological Investigation" (MIBBI) project. === MIAPPE, Minimum Information About a Plant Phenotyping Experiment === MIAPPE is an open, community driven project to harmonize data from plant phenotyping experiments. MIAPPE comprises both a conceptual checklist of metadata required to adequately describe a plant phenotyping experiment. === MIQE, Minimum Information for Publication of Quantitative Real-Time PCR Experiments === Published in 2009 these guidelines for the basis of requirements by many journals when submitting QPCR data, sadly they are not adhered to enough. === MIAME, gene expression microarray === Minimum Information About a Microarray Experiment (MIAME) describes the Minimum Information About a Microarray Experiment that is needed to enable the interpretation of the results of the experiment unambiguously and potentially to reproduce the experiment and is aimed at facilitating the dissemination of data from microarray experiments. It was published by the FGED Society in 2001 and was the first published minimum information standard for high-throughput experiments in the life sciences. MIAME contains a number of extensions to cover specific biological domains, including MIAME-env, MIAME-nut and MIAME-tox, covering environmental genomics, nutritional genomics and toxogenomics, respectively. === MINI: Minimum Information about a Neuroscience Investigation === ==== MINI: Electrophysiology ==== Electrophysiology is a technology used to study the electrical properties of biological cells and tissues. Electrophysiology typically involves the measurements of voltage change or electric current flow on a wide variety of scales from single ion channel proteins to whole tissues. This document is a single module, as part of the Minimum Information about a Neuroscience investigation (MINI) family of reporting guideline documents, produced by community consultation and continually available for public comment. A MINI module represents the minimum information that should be reported about a dataset to facilitate computational access and analysis to allow a reader to interpret and critically evaluate the processes performed and the conclusions reached, and to support their experimental corroboration. In practice a MINI module comprises a checklist of information that should be provided (for example about the protocols employed) when a data set is described for publication. The full specification of the MINI module can be found here. === MIARE, RNAi experiment === Minimum Information About an RNAi Experiment (MIARE) is a data reporting guideline which describes the minimum information that should be reported about an RNAi experiment to enable the unambiguous interpretation and reproduction of the results. === MIACA, cell based assay === Advances in genomics and functional genomics have enabled large-scale analyses of gene and protein function by means of high-throughput cell biological analyses. Thereby, cells in culture can be perturbed in vitro and the induced effects recorded and analyzed. Perturbations can be triggered in several ways, for instance with molecules (siRNAs, expression constructs, small chemical compounds, ligands for receptors, etc.), through environmental stresses (such as temperature shift, serum starvation, oxygen deprivation, etc.), or combinations thereof. The cellular responses to such perturbations are analyzed in order to identify molecular events in the biological processes addressed and understand biological principles. We propose the Minimum Information About a Cellular Assay (MIACA) for reporting a cellular assay, and CA-OM, the modular cellular assay object model, to facilitate exchange of data and accompanying information, and to compare and integrate data that originate from different, albeit complementary approaches, and to elucidate higher order principles. Documents describing MIACA are available and provide further information as well as the checklist of terms that should be reported. === MIAPE, proteomic experiments === The Minimum Information About a Proteomic Experiment documents describe information which should be given along with a proteomic experiment. The parent document describes the processes and principles underpinning the development of a series of domain specific documents which now cover all aspects of a MS-based proteomics workflow. === MIMIx, molecular interactions === This document has been developed and maintained by the Molecular Interaction worktrack of the HUPO-PSI (www.psidev.info) and describes the Minimum Information about a Molecular Interaction experiment. === MIAPAR, protein affinity reagents === The Minimum Information About a Protein Affinity Reagent has been developed and maintained by the Molecular Interaction worktrack of the HUPO-PSI (www.psidev.info)in conjunction with the HUPO Antibody Initiative and a European consortium of binder producers and seeks to encourage users to improve their description of binding reagents, such as antibodies, used in the process of protein identification. === MIABE, bioactive entities === The Minimum Information About a Bioactive Entity was produced by representatives from both large pharma and academia who are looking to improve the description of usually small molecules which bind to, and potentially modulate the activity of, specific targets in a living organism. This document encompasses drug-like molecules as well as herbicides, pesticides and food additives. It is primarily maintained through the EMBL-EBI Industry program (www.ebi.ac.uk/industry). === MIGS/MIMS, genome/metagenome sequences === This specification is being developed by the Genomic Standards Consortium === MIFlowCyt, flow cytometry === === Minimum Information about a Flow Cytometry Experiment === The Minimum Information about a Flow Cytometry Experiment (MIFlowCyt) is a standard related to flow cytometry which establishes criteria to record information on experimental overview, samples, instrumentation and data analysis. It promotes consistent annotation of clinical, biological and technical issues surrounding a flow cytometry experiment. === MINDR, dual gene expression reporters === Requires (1) reporting absolute values of reporter readouts, (2) list of positive and negative controls, and (3) sequences of all reporter constructs. === MISFISHIE, In Situ Hybridization and Immunohistochemistry Experiments === === MIAPA, Phylogenetic Analysis === Criteria for Minimum Information About a Phylogenetic Analysis were described in 2006. === MIRAGE, Glycomics === The MIRAGE project is supported and coordinated by the Beilstein-Institut to establish guidelines for data handling and processing in glycomics research [1] === MIAO, ORF === === MIAMET, METabolomics experiment === === MIAFGE, Functional Genomics Experiment === === MIRIAM, Minimum Information Required in the Annotation of Models === The Minimal Information Required In the Annotation of Models (MIRIAM), is a set of rules for the curation and annotation of quantitative models of biological systems. === MIASE, Minimum Information About a Simulation Experiment =

    Read more →