Statistical shape analysis is an analysis of the geometrical properties of some given set of shapes by statistical methods. For instance, it could be used to quantify differences between male and female gorilla skull shapes, normal and pathological bone shapes, leaf outlines with and without herbivory by insects, etc. Important aspects of shape analysis are to obtain a measure of distance between shapes, to estimate mean shapes from (possibly random) samples, to estimate shape variability within samples, to perform clustering and to test for differences between shapes. One of the main methods used is principal component analysis (PCA). Statistical shape analysis has applications in various fields, including medical imaging, computer vision, computational anatomy, sensor measurement, and geographical profiling. == Landmark-based techniques == In the point distribution model, a shape is determined by a finite set of coordinate points, known as landmark points. These landmark points often correspond to important identifiable features such as the corners of the eyes. Once the points are collected some form of registration is undertaken. This can be a baseline methods used by Fred Bookstein for geometric morphometrics in anthropology. Or an approach like Procrustes analysis which finds an average shape. David George Kendall investigated the statistical distribution of the shape of triangles, and represented each triangle by a point on a sphere. He used this distribution on the sphere to investigate ley lines and whether three stones were more likely to be co-linear than might be expected. Statistical distribution like the Kent distribution can be used to analyse the distribution of such spaces. Alternatively, shapes can be represented by curves or surfaces representing their contours, by the spatial region they occupy. == Shape deformations == Differences between shapes can be quantified by investigating deformations transforming one shape into another. In particular a diffeomorphism preserves smoothness in the deformation. This was pioneered in D'Arcy Thompson's On Growth and Form before the advent of computers. Deformations can be interpreted as resulting from a force applied to the shape. Mathematically, a deformation is defined as a mapping from a shape x to a shape y by a transformation function Φ {\displaystyle \Phi } , i.e., y = Φ ( x ) {\displaystyle y=\Phi (x)} . Given a notion of size of deformations, the distance between two shapes can be defined as the size of the smallest deformation between these shapes. Diffeomorphometry is the focus on comparison of shapes and forms with a metric structure based on diffeomorphisms, and is central to the field of Computational anatomy. Diffeomorphic registration, introduced in the 90's, is now an important player with existing codes bases organized around ANTS, DARTEL, DEMONS, LDDMM, StationaryLDDMM, and FastLDDMM are examples of actively used computational codes for constructing correspondences between coordinate systems based on sparse features and dense images. Voxel-based morphometry (VBM) is an important technology built on many of these principles. Methods based on diffeomorphic flows are also used. For example, deformations could be diffeomorphisms of the ambient space, resulting in the LDDMM (Large Deformation Diffeomorphic Metric Mapping) framework for shape comparison.
Hybrid intelligent system
Hybrid intelligent system denotes a software system which employs, in parallel, a combination of methods and techniques from artificial intelligence subfields, such as: Neuro-symbolic systems Neuro-fuzzy systems Hybrid connectionist-symbolic models Fuzzy expert systems Connectionist expert systems Evolutionary neural networks Genetic fuzzy systems Rough fuzzy hybridization Reinforcement learning with fuzzy, neural, or evolutionary methods as well as symbolic reasoning methods. From the cognitive science perspective, every natural intelligent system is hybrid because it performs mental operations on both the symbolic and subsymbolic levels. For the past few years, there has been an increasing discussion of the importance of A.I. Systems Integration. Based on notions that there have already been created simple and specific AI systems (such as systems for computer vision, speech synthesis, etc., or software that employs some of the models mentioned above) and now is the time for integration to create broad AI systems. Proponents of this approach are researchers such as Marvin Minsky, Ron Sun, Aaron Sloman, Angelo Dalli and Michael A. Arbib. An example hybrid is a hierarchical control system in which the lowest, reactive layers are sub-symbolic. The higher layers, having relaxed time constraints, are capable of reasoning from an abstract world model and performing planning (even by hybrid wisdom). Intelligent systems usually rely on hybrid reasoning processes, which include induction, deduction, abduction and reasoning by analogy.
PyTorch
PyTorch is an open-source deep learning library, originally developed by Meta Platforms and currently developed with support from the Linux Foundation. The successor to Torch, PyTorch provides a high-level API that builds upon optimised, low-level implementations of deep learning algorithms and architectures, such as the Transformer, or SGD. Notably, this API simplifies model training and inference to a few lines of code. PyTorch allows for automatic parallelization of training and, internally, implements CUDA bindings that speed training further by leveraging GPU resources. PyTorch utilises the tensor as a fundamental data type, similarly to NumPy. Training is facilitated by a reversed automatic differentiation system, Autograd, that constructs a directed acyclic graph of the operations (and their arguments) executed by a model during its forward pass. With a loss, backpropagation is then undertaken. As of 2025, PyTorch remains one of the most popular deep learning libraries, alongside others such as TensorFlow and Keras. It can be installed using Anaconda package managers. A number of commercial deep learning architectures are built on top of PyTorch, including ChatGPT, Tesla Autopilot, Uber's Pyro, and Hugging Face's Transformers. == History == In 2001, Torch was written and released under a GPL. It was a machine-learning library written in C++ and CUDA, supporting methods including neural networks, support vector machines (SVM), hidden Markov models, etc. Around 2010, it was rewritten by Ronan Collobert, Clement Farabet and Koray Kavuckuoglu. This was known as Torch7 or LuaTorch. This was written so that the backend was in C and the frontend was in Lua. In mid-2016, some developers refactored it to decouple the frontend and the backend, with strong influence from torch-autograd and Chainer. In turn, torch-autograd was influenced by HIPS/autograd. Development on Torch7 ceased in 2018 and was subsumed by the PyTorch project. Meta (formerly known as Facebook) operates both PyTorch and Convolutional Architecture for Fast Feature Embedding (Caffe2), but models defined by the two frameworks were mutually incompatible. The Open Neural Network Exchange (ONNX) project was created by Meta and Microsoft in September 2017 to decouple deep learning frameworks from hardware-specific runtimes, allowing models to be converted between frameworks and optimized for execution providers like NVIDIA’s TensorRT. Caffe2 was merged into PyTorch at the end of March 2018. In September 2022, Meta announced that PyTorch would be governed by the independent PyTorch Foundation, a newly created subsidiary of the Linux Foundation. PyTorch 2.0 was released on 15 March 2023, introducing TorchDynamo, a Python-level compiler that makes code run up to two times faster, along with significant improvements in training and inference performance across major cloud platforms. == PyTorch tensors == PyTorch defines a class called Tensor (torch.Tensor) to store and operate on homogeneous multidimensional rectangular arrays of numbers. PyTorch supports various sub-types of multi-dimensional arrays, or Tensors. PyTorch Tensors are similar to NumPy Arrays, but can also be operated on by a CUDA-capable NVIDIA GPU. PyTorch has also been developing support for other GPU platforms, for example, AMD's ROCm and Apple's Metal Framework. == PyTorch neural networks == PyTorch defines a module called nn (torch.nn) to describe neural networks and to support training. This module offers a comprehensive collection of building blocks for neural networks, including various layers and activation functions, enabling the construction of complex models. Networks are built by inheriting from the torch.nn module and defining the sequence of operations in the forward() function. == PyTorch Serialized File Format == Pytorch can save and load models using its own file format, which is a ZIP64 archive containing the model weights in a Python pickle file, and other information such as the byte order. The file extensions .pt and .pth are commonly used for these files. == Example == The following program shows the low-level functionality of the library with a simple example. The following code block defines a neural network with linear layers using the nn module.
General-Purpose AI Code of Practice
The General-Purpose AI Code of Practice (GPAI CoP) is a compliance tool released by the European Commission on 10 July 2025 to support compliance with the European Union Artificial Intelligence Act (AI Act). It provides operational guidance for providers of general-purpose AI models, particularly in relation to Articles 53 and 55 of the AI Act, which entered into application on 2 August 2025. The Code is organised into three chapters (Transparency, Copyright, and Safety and Security) and outlines how providers can meet the Act's relevant obligations. Although non-binding, providers can rely on adherence to the Code, meaning that EU regulators will assume that providers following the Code meet the corresponding legal requirements of the AI Act. As such, signatories to the Code will benefit from reduced administrative burdens and increased legal certainty compared to providers that prove compliance in other ways. While adherence to the Code is voluntary, compliance with the AI Act is not. == Background == The EU AI Act, adopted in 2024, established a risk-based regulatory regime for artificial intelligence in the European Union. The rationale for the GPAI CoP stems from Article 56 of the AI Act, which empowers the EU AI Office to develop a voluntary rulebook to guide how AI model providers can meet their legal obligations – specifically those found in Articles 53 and 55. Under Articles 53 and 55, developers of general-purpose AI models whose training compute exceeds 1023 floating-point operations (FLOPs) and that are placed on the EU market must meet transparency obligations and put in place a policy for EU copyright law. Models trained with more than 1025 FLOPs are classified as presenting systemic risk and are subject to enhanced safety requirements. The Commission may also designate a model as presenting systemic risk if it has equivalent impact or capabilities (Annex XIII criteria), even below that compute figure. Because the AI Act is relatively vague on how model providers should implement these requirements, the Code is meant to help by detailing processes and practices for compliance. == Drafting process == The development of the GPAI CoP was drawn up by 13 independent experts and involved four thematic working groups: Transparency & Copyright, Risk assessment for systemic risk, Technical risk mitigation for systemic risk, and Governance risk mitigation for systemic risk. Each group was coordinated by the European Union Artificial Intelligence Office (EU AI Office), drawing on contributions from nearly 1,000 stakeholders, including AI developers, academics, civil society organisations, national authorities, and international observers. The Code underwent three earlier iterations in November 2024, December 2024, and March 2025, before the final version was published on 10 July 2025, more than two months later than initially planned. The GPAI CoP will likely be updated continuously by the EU AI Office, alongside other tools such as the training data summary template. == Signatories == Among U.S.-based technology companies, Amazon, Anthropic, Google, IBM, Microsoft, and OpenAI have signed the GPAI CoP. xAI, founded by Elon Musk, has signed only one of the three chapters, namely the safety and security chapter. Prominent European AI companies that have signed include Aleph Alpha and Mistral AI. The European Commission maintains an updated list of signatories. As of January 2026, Meta is the most notable company that has declined to sign the Code. Major Chinese AI companies, such as Alibaba, Baidu or Deepseek, have also not signed. Providers that do not sign the GPAI CoP will still have to adhere to the binding requirements of the EU AI Act. The European Commission has indicated that it may take tougher action against companies that didn't sign the Code. == Transparency and Copyright chapters == The first two chapters of the GPAI CoP address transparency and copyright compliance and apply to all GPAI providers. They offer a way to demonstrate compliance with their obligations under Article 53 AI Act. The Transparency chapter addresses the documentation of a model's capabilities, limitations, and points of contact, and expects providers to make key documentation available to downstream providers. Signatories must also publish summaries of the content used to train their models. In the Copyright chapter, Signatories commit to follow a policy that aligns with EU copyright law. For example, they commit to mitigating the risk of copyright-infringing output. == Safety and Security chapter == The Safety and Security chapter is the most extensive chapter of the Code, and it applies to GPAI models with systemic risk, meaning it's only relevant to the small number of providers of the most advanced models. It specifies how Signatories commit to meeting Article 55(1) obligations to: Conduct model evaluations to identify systemic risks Assess and mitigate those risks Track and report serious incidents Ensure the cyber and physical security of their models The chapter outlines a comprehensive risk management process that must be applied before major deployment decisions, such as releasing a new systemic-risk GPAI model in the EU market, or substantially updating an existing one. Signatories commit to identifying systemic risks of their model, analysing and evaluating them, determining whether risk levels are acceptable, and implementing mitigation measures if necessary. This process should be repeated until models achieve an acceptable level of risk across all identified risks. === Risk identification === Signatories commit to analysing and evaluating at least four “specified” categories of systemic risk: CBRN (chemical, biological, radiological, and nuclear) Loss of control Cyber offence Harmful manipulation They are also expected to identify other systemic risks to public health, safety, and fundamental rights. The Code instructs providers to consider model capabilities, propensities, and affordances in this identification. Signatories commit to developing risk scenarios illustrating how identified risks could materialise in real-world conditions. === Risk analysis and risk evaluation === After identifying potential systemic risks, Signatories commit to analysing and evaluating the risks in order to determine whether they are acceptable or not, drawing on scientific literature, training data analysis, incident databases, expert consultation, and other sources. They also commit to conducting state-of-the-art model evaluations such as benchmarking, red teaming, and human uplift studies, targeting each risk. The risk analysis process is interconnected: insights from risk modelling should inform model evaluation design, while post-market monitoring should feed back into ongoing analysis. Signatories commit to ultimately estimating the likelihood and severity of each systemic risk. ==== Independent external model evaluations ==== Appendix 3.5 of the Safety and Security chapter requires signatories to ensure that independent external evaluators conduct model evaluations. Signatories may claim an exemption from this requirement only if they can demonstrate that their model is “similarly safe” to another model that has already been shown to comply with the Code, or if they are unable to appoint an appropriately qualified evaluator. The determination of “similarly safe” is based on comparable performance on benchmarks and the similarity of other model characteristics, such as their architecture. The CoP acknowledges that this kind of information is typically available only for models by the same provider, or potentially for open-weights or open-source models. === Risk acceptance criteria === The Code requires providers to compare estimated risks against predefined acceptance criteria, which must be measurable, based on model capabilities, and defined preemptively. While providers get to determine the level of risk they deem acceptable themselves, the pre-defined criteria and acceptance thresholds ensure providers cannot adjust their level of tolerance flexibly ahead of deployment decisions. Only if all risks are below acceptable levels should a model be deployed. === Continuous risk management and governance === The Code mandates ongoing risk management throughout the model lifecycle, including light-touch evaluations, continuous mitigation, post-market monitoring, and incident tracking and reporting. It further requires organisational governance structures assigning responsibility for risk management and expects providers to promote a “healthy risk culture,” including informing employees about the whistleblower protection policy, allowing internal challenges of decisions concerning systemic risk management, and committing to not retaliating against employees who disclose concerns about systemic risks to oversight authorities. === Documentation and transparency === Signatories commit to creating two types of documentation: Safety and Security Frame
Semantic triple
A semantic triple, or RDF triple or simply triple, is the atomic data entity in the Resource Description Framework (RDF) data model. As its name indicates, a triple is a sequence of three entities that codifies a statement about semantic data in the form of subject–predicate–object expressions (e.g., "Bob is 35", or "Bob knows John"). == Subject, predicate and object == This format enables knowledge to be represented in a machine-readable way. Particularly, every part of an RDF triple is individually addressable via unique URIs—for example, the statement "Bob knows John" might be represented in RDF as: http://example.name#BobSmith12 http://xmlns.com/foaf/spec/#term_knows http://example.name#JohnDoe34. Given this precise representation, semantic data can be unambiguously queried and reasoned about. The components of a triple, such as the statement "The sky has the color blue", consist of a subject ("the sky"), a predicate ("has the color"), and an object ("blue"). This is similar to the classical notation of an entity–attribute–value model within object-oriented design, where this example would be expressed as an entity (sky), an attribute (color) and a value (blue). From this basic structure, triples can be composed into more complex models, by using triples as objects or subjects of other triples—for example, Mike → said → (triples → can be → objects). Given their particular, consistent structure, a collection of triples is often stored in purpose-built databases called triplestores. == Difference from relational databases == A relational database is the classical form for information storage, working with different tables, which consist of rows. The query language SQL is able to retrieve information from such a database. In contrast, RDF triple storage works with logical predicates. No tables nor rows are needed, but the information is stored in a text file. An RDF-triple store can be converted into an SQL database and the other way around. If the knowledge is highly unstructured and dedicated tables aren't flexible enough, semantic triples are used over classic relational storage. In contrast to a traditional SQL database, an RDF triple store isn't created with a table editor. The preferred tool is a knowledge editor, for example Protégé. Protégé looks similar to an object-oriented modeling application used for software engineering, but it's focused on natural language information. The RDF triples are aggregated into a knowledge base, which allows external parsers to run requests. Possible applications include the creation of non-player characters within video games. == Limitations == One concern about triple storage is its lack of database scalability. This problem is especially pertinent if millions of triples are stored and retrieved in a database. The seek time is larger than for classical SQL-based databases. A more complex issue is a knowledge model's inability to predict future states. Even if all the domain knowledge is available as logical predicates, the model fails in answering what-if questions. For example, suppose in the RDF format a room with a robot and table is described. The robot knows what the location of the table is, is aware of the distance to the table and knows also that a table is a type of furniture. Before the robot can plan its next action, it needs temporal reasoning capabilities. Thus, the knowledge model should answer hypothetical questions in advance before an action is taken.
Collateral freedom
Collateral freedom is an anti-censorship strategy that attempts to make it economically prohibitive for censors to block content on the Internet. This is achieved by hosting content on cloud services that are considered by censors to be "too important to block", and then using encryption to prevent censors from identifying requests for censored information that is hosted among other content, forcing censors to either allow access to the censored information or take down entire services.
Production Rule Representation
The Production Rule Representation (PRR) is a proposed standard of the Object Management Group (OMG) that aims to define a vendor-neutral model for representing production rules within the Unified Modeling Language (UML), specifically for use in forward-chaining rule engines. == History == The OMG set up a Business Rules Working Group in 2002 as the first standards body to recognize the importance of the "Business Rules Approach". It issued 2 main RFPs in 2003 – a standard for modeling production rules (PRR), and a standard for modeling business rules as business documentation (BSBR, now SBVR). PRR was mostly defined by and for vendors of Business Rule Engines (BREs) (sometimes termed Business Rules Engine(s), like in Wikipedia). Contributors have included all the major BRE vendors, members of RuleML, and leading UML vendors. == Evolution == The PRR RFP originally suggested that PRR use a combination of UML OCL and Action Semantics for rule conditions and actions. However, expecting modellers to learn 2 relatively obscure UML languages in order to define a production rule proved unpalatable. Therefore, PRR OCL was defined that included OCL extensions for simple rule actions (as well as external functions). PRR OCL is currently considered "non-normative" i.e. is not part of the PRR standard per se. PRR beta applies just to a PRR Core that excludes an explicit expression language. The PRR RFP envisaged covering both forward and backward chaining rule engines. However, the lack of vendor support for / interest in backward chaining caused this to be revise to forward chaining and "sequential" semantics. The latter is simply the scripting mode provided by many BPM tools, where rules are listed and executed sequentially as if programmed. This provides PRR with better compatibility with typical BPM scripting engines (and acknowledges the fact that most BREs today support a "sequential" mode of operation, improving performance in some circumstances). == Status == PRR is currently at version 1.0.