State complexity

State complexity

State complexity is an area of theoretical computer science dealing with the size of abstract automata, such as different kinds of finite automata. The classical result in the area is that simulating an n {\displaystyle n} -state nondeterministic finite automaton by a deterministic finite automaton requires exactly 2 n {\displaystyle 2^{n}} states in the worst case. == Transformation between variants of finite automata == Finite automata can be deterministic and nondeterministic, one-way (DFA, NFA) and two-way (2DFA, 2NFA). Other related classes are unambiguous (UFA), self-verifying (SVFA) and alternating (AFA) finite automata. These automata can also be two-way (2UFA, 2SVFA, 2AFA). All these machines can accept exactly the regular languages. However, the size of different types of automata necessary to accept the same language (measured in the number of their states) may be different. For any two types of finite automata, the state complexity tradeoff between them is an integer function f {\displaystyle f} where f ( n ) {\displaystyle f(n)} is the least number of states in automata of the second type sufficient to recognize every language recognized by an n {\displaystyle n} -state automaton of the first type. The following results are known. NFA to DFA: 2 n {\displaystyle 2^{n}} states. This is the subset construction by Rabin and Scott, proved optimal by Lupanov. UFA to DFA: 2 n {\displaystyle 2^{n}} states, see Leung, An earlier lower bound by Schmidt was smaller. NFA to UFA: 2 n − 1 {\displaystyle 2^{n}-1} states, see Leung. There was an earlier smaller lower bound by Schmidt. SVFA to DFA: Θ ( 3 n / 3 ) {\displaystyle \Theta (3^{n/3})} states, see Jirásková and Pighizzini 2DFA to DFA: n ( n n − ( n − 1 ) n ) {\displaystyle n(n^{n}-(n-1)^{n})} states, see Kapoutsis. Earlier construction by Shepherdson used more states, and an earlier lower bound by Moore was smaller. 2DFA to NFA: ( 2 n n + 1 ) = O ( 4 n n ) {\displaystyle {\binom {2n}{n+1}}=O({\frac {4^{n}}{\sqrt {n}}})} , see Kapoutsis. Earlier construction by Birget used more states. 2NFA to NFA: ( 2 n n + 1 ) {\displaystyle {\binom {2n}{n+1}}} , see Kapoutsis. 2NFA to NFA accepting the complement: O ( 4 n ) {\displaystyle O(4^{n})} states, see Vardi. AFA to DFA: 2 2 n {\displaystyle 2^{2^{n}}} states, see Chandra, Kozen and Stockmeyer. AFA to NFA: 2 n {\displaystyle 2^{n}} states, see Fellah, Jürgensen and Yu. 2AFA to DFA: 2 n 2 n {\displaystyle 2^{n2^{n}}} , see Ladner, Lipton and Stockmeyer. 2AFA to NFA: 2 Θ ( n log ⁡ n ) {\displaystyle 2^{\Theta (n\log n)}} , see Geffert and Okhotin. === The 2DFA vs. 2NFA problem and logarithmic space === It is an open problem whether all 2NFAs can be converted to 2DFAs with polynomially many states, i.e. whether there is a polynomial p ( n ) {\displaystyle p(n)} such that for every n {\displaystyle n} -state 2NFA there exists a p ( n ) {\displaystyle p(n)} -state 2DFA. The problem was raised by Sakoda and Sipser, who compared it to the P vs. NP problem in the computational complexity theory. Berman and Lingas discovered a formal relation between this problem and the L vs. NL open problem. This relation was further elaborated by Kapoutsis. == State complexity of operations for finite automata == Given a binary regularity-preserving operation on languages ∘ {\displaystyle \circ } and a family of automata X (DFA, NFA, etc.), the state complexity of ∘ {\displaystyle \circ } is an integer function f ( m , n ) {\displaystyle f(m,n)} such that for each m-state X-automaton A and n-state X-automaton B there is an f ( m , n ) {\displaystyle f(m,n)} -state X-automaton for L ( A ) ∘ L ( B ) {\displaystyle L(A)\circ L(B)} , and for all integers m, n there is an m-state X-automaton A and an n-state X-automaton B such that every X-automaton for L ( A ) ∘ L ( B ) {\displaystyle L(A)\circ L(B)} must have at least f ( m , n ) {\displaystyle f(m,n)} states. Analogous definition applies for operations with any number of arguments. The first results on state complexity of operations for DFAs were published by Maslov and by Yu, Zhuang and Salomaa. Holzer and Kutrib pioneered the state complexity of operations on NFA. The known results for basic operations are listed below. === Union === If language L 1 {\displaystyle L_{1}} requires m states and language L 2 {\displaystyle L_{2}} requires n states, how many states does L 1 ∪ L 2 {\displaystyle L_{1}\cup L_{2}} require? DFA: m n {\displaystyle mn} states, see Maslov and Yu, Zhuang and Salomaa. NFA: m + n + 1 {\displaystyle m+n+1} states, see Holzer and Kutrib. UFA: at least min ( n , m ) Ω ( log ⁡ ( min ( n , m ) ) ) {\displaystyle \min(n,m)^{\Omega (\log(\min(n,m)))}} ; between m n + m + n {\displaystyle mn+m+n} and m + n m 2 0.79 m {\displaystyle m+nm2^{0.79m}} states, see Jirásek, Jirásková and Šebej. SVFA: m n {\displaystyle mn} states, see Jirásek, Jirásková and Szabari. 2DFA: between m + n {\displaystyle m+n} and 4 m + n + 4 {\displaystyle 4m+n+4} states, see Kunc and Okhotin. 2NFA: m + n {\displaystyle m+n} states, see Kunc and Okhotin. === Intersection === How many states does L 1 ∩ L 2 {\displaystyle L_{1}\cap L_{2}} require? DFA: m n {\displaystyle mn} states, see Maslov and Yu, Zhuang and Salomaa. NFA: m n {\displaystyle mn} states, see Holzer and Kutrib. UFA: m n {\displaystyle mn} states, see Jirásek, Jirásková and Šebej. SVFA: m n {\displaystyle mn} states, see Jirásek, Jirásková and Szabari. 2DFA: between m + n {\displaystyle m+n} and m + n + 1 {\displaystyle m+n+1} states, see Kunc and Okhotin. 2NFA: between m + n {\displaystyle m+n} and m + n + 1 {\displaystyle m+n+1} states, see Kunc and Okhotin. === Complementation === If language L requires n states then how many states does its complement require? DFA: n {\displaystyle n} states, by exchanging accepting and rejecting states. NFA: 2 n {\displaystyle 2^{n}} states, see Birget. or Jirásková UFA: at least n Ω ~ ( log ⁡ n ) {\displaystyle n^{{\tilde {\Omega }}(\log n)}} states, see Göös, Kiefer and Yuan, (this follows an earlier bound by Raskin); and at most n + 1 ⋅ 2 0.5 n {\displaystyle {\sqrt {n+1}}\cdot 2^{0.5n}} states, see Indzhev and Kiefer. SVFA: n {\displaystyle n} states, by exchanging accepting and rejecting states. 2DFA: at least n {\displaystyle n} and at most 4 n {\displaystyle 4n} states, see Geffert, Mereghetti and Pighizzini. === Concatenation === How many states does L 1 L 2 = { w 1 w 2 ∣ w 1 ∈ L 1 , w 2 ∈ L 2 } {\displaystyle L_{1}L_{2}=\{w_{1}w_{2}\mid w_{1}\in L_{1},w_{2}\in L_{2}\}} require? DFA: m ⋅ 2 n − 2 n − 1 {\displaystyle m\cdot 2^{n}-2^{n-1}} states, see Maslov and Yu, Zhuang and Salomaa. NFA: m + n {\displaystyle m+n} states, see Holzer and Kutrib. UFA: 3 4 2 m + n − 1 {\displaystyle {\frac {3}{4}}2^{m+n}-1} states, see Jirásek, Jirásková and Šebej. SVFA: Θ ( 3 n / 3 2 m ) {\displaystyle \Theta (3^{n/3}2^{m})} states, see Jirásek, Jirásková and Szabari. 2DFA: at least 2 Ω ( n ) log ⁡ m {\displaystyle {\frac {2^{\Omega (n)}}{\log m}}} and at most 2 m m + 1 ⋅ 2 n n + 1 {\displaystyle 2m^{m+1}\cdot 2^{n^{n+1}}} states, see Jirásková and Okhotin. === Kleene star === DFA: 3 4 2 n {\displaystyle {\frac {3}{4}}2^{n}} states, see Maslov and Yu, Zhuang and Salomaa. NFA: n + 1 {\displaystyle n+1} states, see Holzer and Kutrib. UFA: 3 4 2 n {\displaystyle {\frac {3}{4}}2^{n}} states, see Jirásek, Jirásková and Šebej. SVFA: 3 4 2 n {\displaystyle {\frac {3}{4}}2^{n}} states, see Jirásek, Jirásková and Szabari. 2DFA: at least 1 n 2 n 2 − 1 {\displaystyle {\frac {1}{n}}2^{{\frac {n}{2}}-1}} and at most 2 O ( n n + 1 ) {\displaystyle 2^{O(n^{n+1})}} states, see Jirásková and Okhotin. === Reversal === DFA: 2 n {\displaystyle 2^{n}} states, see Mirkin, Leiss, and Yu, Zhuang and Salomaa. NFA: n + 1 {\displaystyle n+1} states, see Holzer and Kutrib. UFA: n {\displaystyle n} states. SVFA: 2 n + 1 {\displaystyle 2n+1} states, see Jirásek, Jirásková and Szabari. 2DFA: between n + 1 {\displaystyle n+1} and n + 2 {\displaystyle n+2} states, see Jirásková and Okhotin. == Finite automata over a unary alphabet == State complexity of finite automata with a one-letter (unary) alphabet, pioneered by Chrobak, is different from the multi-letter case. Let g ( n ) = e Θ ( n ln ⁡ n ) {\displaystyle g(n)=e^{\Theta ({\sqrt {n\ln n}})}} be Landau's function. === Transformation between models === For a one-letter alphabet, transformations between different types of finite automata are sometimes more efficient than in the general case. NFA to DFA: g ( n ) + O ( n 2 ) {\displaystyle g(n)+O(n^{2})} states, see Chrobak. 2DFA to DFA: g ( n ) + O ( n ) {\displaystyle g(n)+O(n)} states, see Chrobak and Kunc and Okhotin. 2NFA to DFA: O ( g ( n ) ) {\displaystyle O(g(n))} states, see Mereghetti and Pighizzini. and Geffert, Mereghetti and Pighizzini. NFA to 2DFA: at most O ( n 2 ) {\displaystyle O(n^{2})} states, see Chrobak. 2NFA to 2DFA: at most n O ( log ⁡ n ) {\displaystyle n^{O(\log n)}} states, proved by implementing the method of Savitch's theorem, see

Clara.io

Clara.io is web-based freemium 3D computer graphics software developed by Exocortex, a Canadian software company. The free or "Basic" component of their freemium offering, however, places severe restrictions, such as on saving models and importing texture maps, which are undisclosed in the company's own descriptions of their plans.vf TMN == History == Clara.io was announced in July 2013, and first presented as part of the official SIGGRAPH 2013 program later that month. By November 2013, when the open beta period started, Clara.io had 14,000 registered users. Clara.io claimed to have 26,000 registered users in January 2014, which grew to 85,000 by December 2014. Clara.io was permanently shut down on December 31, 2022, but the site is currently still partially functional to logged-in users. == Features == Polygonal modeling Constructive solid geometry Key frame animation Skeletal animation Hierarchical scene graph Texture mapping Photorealistic rendering (streaming cloud rendering using V-Ray Cloud) Scene publishing via HTML iframe embedding FBX, Collada, OBJ, STL and Three.js import/export Collaborative real-time editing Revision control (versioning & history) Scripting, Plugins & REST APIs 3D model library Unlisted and Private scenes (paid subscriptions only). == Technology == Clara.io is developed using HTML5, JavaScript, WebGL and Three.js. Clara.io does not rely on any browser plugins and thus runs on any platform that has a modern standards compliant browser. == Screenshots ==

Content management

Content management (CM) are a set of processes and technologies that support the collection, managing, and publishing of information in any form or medium. When stored and accessed via computers, this information may be more specifically referred to as digital content, or simply as content. Digital content may take the form of text (such as electronic documents), images, multimedia files (such as audio or video files), or any other file type that follows a content lifecycle requiring management. The process of content development and management is complex enough that various commercial software vendors (large and small), such as Interwoven and Microsoft, offer content management software to control and automate significant aspects of the content lifecycle. == Process == Content management practices and goals vary by mission and by organizational governance structure. News organizations, e-commerce websites, and educational institutions all use content management, but in different ways. This leads to differences in terminology and in the names and number of steps in the process. For example, some digital content is created by one or more authors. Over time that content may be edited. One or more individuals may provide some editorial oversight, approving the content for publication. Publishing may take many forms: it may be the act of "pushing" content out to others, or simply granting digital access rights to certain content to one or more individuals. Later that content may be superseded by another version of the content and thus retired or removed from use (as when this wiki page is modified). Content management is an inherently collaborative process. It often consists of the following basic roles and responsibilities: Creator – responsible for creating and editing content. Editor – responsible for tuning the content message and the style of delivery, including translation and localization. Publisher – responsible for releasing the content for use. Administrator – responsible for managing access permissions to folders, collections and files, usually accomplished by assigning access rights to user groups or roles. Admins may also assist and support users in various ways. Consumer, viewer or guest – the person who reads or otherwise consumes the content after it is published or shared. A critical aspect of content management is the ability to manage versions of content as it evolves (see also version control). Authors and editors often need to restore older versions of edited products due to a process failure or an undesirable series of edits. Time-sensitive content may also require updates as the subject matter evolves over time. Another equally important aspect of content management involves the creation, maintenance, and application of review standards. Each member of the content creation and review process has a unique role and set of responsibilities in the development or publication of the content. Each review team member requires clear and concise review standards. These must be maintained on an ongoing basis to ensure the long-term consistency and health of the knowledge base. A content management system is a set of automated processes that may support the following features: Import and creation of documents and multimedia material Identification of all key users and their roles The ability to assign roles and responsibilities to different instances of content categories or types Definition of workflow tasks often coupled with messaging so that content managers are alerted to changes in content The ability to track and manage multiple versions of a single instance of content The ability to publish the content to a repository to support access The ability to personalize content based on a set of rules Increasingly, the repository is an inherent part of the system, and incorporates enterprise search and retrieval. Content management systems take the following forms: Web content management system—software for web site management (often what content management implicitly means) Output of a newspaper editorial staff organization Workflow for article publication Document management systems Knowledge management software Single source content management system—content stored in chunks within a relational database Variant management system—where personnel tag source content (usually text and graphics) to represent variants stored as single source "master" content modules, resolved to the desired variant at publication (for example: automobile owners manual content for 12 model years stored as single master content files and "called" by model year as needed)—often used in concert with database chunk storage (see above) for large content objects == Governance structures == Content management expert Marc Feldman defines three primary content management governance structures: localized, centralized, and federated—each having its unique strengths and weaknesses. === Localized governance === By putting control in the hands of those closest to the content, the context experts, localized governance models empower and unleash creativity. These benefits come, however, at the cost of a partial-to-total loss of managerial control and oversight. === Centralized governance === When the levers of control are strongly centralized, content management systems are capable of delivering an exceptionally clear and unified brand message. Moreover, centralized content management governance structures allow for a large number of cost-savings opportunities in large enterprises, realized, for example, through (1) the avoidance of duplicated efforts in creating, editing, formatting, repurposing and archiving content; (2) process management and the streamlining of all content related labor; and/or (3) an orderly deployment or updating of the content management system. === Federated governance === Federated governance models potentially realize the benefits of both localized and centralized control while avoiding the weaknesses of both. While content management software systems are inherently structured to enable federated governance models, realizing these benefits can be difficult because it requires, for example, negotiating the boundaries of control with local managers and content creators. In the case of larger enterprises, in particular, the failure to fully implement or realize a federated governance structure equates to a failure to realize the full return on investment and cost savings that content management systems enable. == Implementation == Content management implementations must be able to manage content distributions and digital rights in content life cycle. Content management systems are usually involved with digital rights management in order to control user access and digital rights. In this step, the read-only structures of digital rights management systems force some limitations on content management, as they do not allow authors to change protected content in their life cycle. Creating new content using managed (protected) content is also an issue that gets protected contents out of management controlling systems. A few content management implementations cover all these issues.

Data marketplace

Data marketplace is an online platform for sharing and consuming data in the form of data assets or data products. Part of the data management stack, it aims to bring together data producers and data consumers (including business users and AI) in a single space, with the objective of increasing access to understandable, high-quality data. Included within its Data Marketplaces and Exchange (DME) category by Gartner, data marketplaces can provide data internally within an organization, externally with partners, or as open data. == Concept == Digitization has dramatically increased data volumes within organizations, with IDC predicting that by 2025 the world will contain 175 zettabytes of data. This has created a need to both manage this data and provide access to it to enable business intelligence and data analysis. However, data is often scattered within multiple systems (such as data warehouses and data lakes), and is in formats that are only understandable by technical experts, such as data scientists. According to IDC, 81% of IT leaders cite data silos as a major barrier to digital transformation. This means that data is not freely available to business users or external audiences such as partners or citizens, limiting its value, and holding back AI deployments. Data marketplaces solve this issue, providing seamless, self-service access to high-quality data in an understandable, secure and auditable manner. They break down data silos, reduce friction in data access, and enable a broader range of users, including non-technical profiles, to find, understand, and consume data autonomously. Data assets on the marketplace can be raw data, data visualizations or data products. Data marketplaces combine data management functions such as data governance with the user-friendly experience offered by e-commerce marketplaces in order to increase the usage of data. These include features such as powerful search engines, feedback, ratings, subscriptions and product description sheets. According to Gartner, data marketplaces provide infrastructure, transactional capabilities, and services for both consumers and providers of data assets. == History and timeline == Data marketplaces have evolved since they first emerged in terms of both their scope and usage. === 2000s === With the rise of the internet, data brokers began collecting, aggregating, distributing and selling personal, financial and marketing data to third parties online. Data marketplaces were deployed to monetize this data, making it discoverable and accessible to users, either through subscriptions or one-off purchases. At the same time, regulations, such as the US Open Government Initiative of 2009 and others around the world mandated greater transparency and data sharing with the public. Data sharing portals were created by public and government bodies to make this information available through self-service to all users. === 2010s === Due to the growth of big data and cloud platforms, cloud-based data exchange platforms emerged. These were offered by major infrastructure providers, and included Amazon Web Services (AWS) Data Exchange, Snowflake Data Marketplace, and the Google Cloud Platform. These platforms moved beyond simple data brokerage or open data by providing structured, catalogued data sharing between organizations. === 2020s === Driven by a need to increase internal data sharing with both business users and AI, organizations are now looking to adopt internal data marketplaces. These aim to democratize data consumption by providing seamless access for all employees and AI to trusted data, including data products, through an intuitive, e-commerce style experience. According to Gartner analyst Richa Jha, "by providing a single, governed platform for discovering, sharing, and scaling data products, data marketplaces drive productivity, collaboration, and ROI across the enterprise." == Data marketplaces within the overall data architecture == Data marketplaces provide a consumption and collaboration layer for data. That means they complement and integrate with other parts of the overall data architecture, including: === Data warehouses and data lakes === Data marketplaces connect to data sources, such as data warehouses or data lakes, to provide intuitive access to the data stored within them, enabling data to be shared and distributed to non-technical audiences. Access can be direct, with data and data products stored within the data marketplace or virtualized. === Data catalog === A data catalog provides a technical inventory of an organization's data estate. It collects technical information on all available data assets within an organization, based on metadata descriptions. This ensures traceability, and supports compliance and governance requirements. Unlike a data marketplace, a data catalog does not provide access to data, and is designed to be used by data professionals, rather than the business. This means it lacks an intuitive, understandable interface and is consequently not easily accessible by business users. === Data mesh === Data mesh is an architecture and framework for data management, first defined by Zhamak Dehghani in 2019. It aims to decentralize data ownership to delegate responsibility, empowering teams and focusing on delivering data to users in the form of self-service data products. The data marketplace is a central pillar of data mesh, providing intuitive access to these data products, and creating a collaboration space for data owners and data consumers. === Data product === Data products are high-value, consumable data assets that package high-quality data and associated tools to enable seamless usage by business users at scale. First defined by McKinsey in 2022, they have an identified owner, a service level agreement (SLA), and a reusability logic. == Core components of a data marketplace == A data marketplace typically includes specific core components: === E-commerce style interface === An e-commerce style experience that engages non-technical users, minimizes the need for training and builds confidence and trust in data. Look and feel should be customizable to incorporate corporate design guidelines to ensure consistency with other organizational applications. === Built-in data catalog === As in a standalone data catalog, this indexes all available data, based on metadata that includes type, source, owner, freshness, and quality level. === Discovery and search engine === This enables users to search, filter, explore and discover available data intuitively. As in an e-commerce marketplace, it should be intelligent, and provide relevant results based on natural language queries. === Access control and security management === Data marketplaces will contain data that needs to be protected under regulations such as the General Data Protection Regulation (GDPR) in Europe, the California Consumer Privacy Act (CCPA) in the United States, and sector-specific frameworks in industries such as finance and healthcare. To ensure both security and compliance while maximizing data consumption, the data marketplace should include granular access management and a full audit trail. === Semantic layer and business glossary === Different parts of the business are likely to use different terms to describe data. This leads to inconsistencies and an inability to share data across systems and teams. The semantic layer and business glossary standardize a shared vocabulary and common definitions of business indicators and concepts, providing a single language for data across the business and for AI agents. === Data governance mechanisms === These enforce corporate data governance policies, ensuring data traceability through data lineage, quality certification, usage monitoring, and continuous improvement through user feedback loops. === Collaboration features === As on an e-commerce website, a data marketplace should provide collaboration features that bring together data users and data owners. This includes the ability to rate data products, share use cases, and provide feedback to data owners, creating a community around data and supporting a data-driven culture. == Types of data marketplace == While they share the same underlying technology, data marketplaces can be deployed in three broad ways: === Internal data marketplaces === These bring together data from across an organization and make it available via self-service to employees from across the business. They aim to widen access to data and consequently to improve decision-making and reporting, increase performance and maximize efficiency. === Ecosystem data marketplaces === These extend sharing beyond a single organization, enabling multiple partners (public institutions, industry players, research bodies) to share and consume data within a governed framework. Data can be provided by all parties or simply by one organization and consumed by others. Ecosystem data marketplaces are particularly relevant in

Scalable Coherent Interface

The Scalable Coherent Interface or Scalable Coherent Interconnect (SCI), is a high-speed interconnect standard for shared memory multiprocessing and message passing. The goal was to scale well, provide system-wide memory coherence and a simple interface; i.e. a standard to replace existing buses in multiprocessor systems with one with no inherent scalability and performance limitations. The IEEE Std 1596-1992, IEEE Standard for Scalable Coherent Interface (SCI) was approved by the IEEE standards board on March 19, 1992. It saw some use during the 1990s, but never became widely used and has been replaced by other systems from the early 2000s. == History == Soon after the Fastbus (IEEE 960) follow-on Futurebus (IEEE 896) project in 1987, some engineers predicted it would already be too slow for the high performance computing marketplace by the time it would be released in the early 1990s. In response, a "Superbus" study group was formed in November 1987. Another working group of the standards association of the Institute of Electrical and Electronics Engineers (IEEE) spun off to form a standard targeted at this market in July 1988. It was essentially a subset of Futurebus features that could be easily implemented at high speed, along with minor additions to make it easier to connect to other systems, such as VMEbus. Most of the developers had their background from high-speed computer buses. Representatives from companies in the computer industry and research community included Amdahl, Apple Computer, BB&N, Hewlett-Packard, CERN, Dolphin Server Technology, Cray Research, Sequent, AT&T, Digital Equipment Corporation, McDonnell Douglas, National Semiconductor, Stanford Linear Accelerator Center, Tektronix, Texas Instruments, Unisys, University of Oslo, University of Wisconsin. The original intent was a single standard for all buses in the computer. The working group soon came up with the idea of using point-to-point communication in the form of insertion rings. This avoided the lumped capacitance, limited physical length/speed of light problems and stub reflections in addition to allowing parallel transactions. The use of insertion rings is credited to Manolis Katevenis who suggested it at one of the early meetings of the working group. The working group for developing the standard was led by David B. Gustavson (chair) and David V. James (Vice Chair). David V. James was a major contributor for writing the specifications including the executable C-code. Stein Gjessing’s group at the University of Oslo used formal methods to verify the coherence protocol and Dolphin Server Technology implemented a node controller chip including the cache coherence logic. Different versions and derivatives of SCI were implemented by companies like Dolphin Interconnect Solutions, Convex, Data General AViiON (using cache controller and link controller chips from Dolphin), Sequent and Cray Research. Dolphin Interconnect Solutions implemented a PCI and PCI-Express connected derivative of SCI that provides non-coherent shared memory access. This implementation was used by Sun Microsystems for its high-end clusters, Thales Group and several others including volume applications for message passing within HPC clustering and medical imaging. SCI was often used to implement non-uniform memory access architectures. It was also used by Sequent Computer Systems as the processor memory bus in their NUMA-Q systems. Numascale developed a derivative to connect with coherent HyperTransport. == The standard == The standard defined two interface levels: The physical level that deals with electrical signals, connectors, mechanical and thermal conditions The logical level that describes the address space, data transfer protocols, cache coherence mechanisms, synchronization primitives, control and status registers, and initialization and error recovery facilities. This structure allowed new developments in physical interface technology to be easily adapted without any redesign on the logical level. Scalability for large systems is achieved through a distributed directory-based cache coherence model. (The other popular models for cache coherency are based on system-wide eavesdropping (snooping) of memory transactions – a scheme which is not very scalable.) In SCI each node contains a directory with a pointer to the next node in a linked list that shares a particular cache line. SCI defines a 64-bit flat address space (16 exabytes) where 16 bits are used for identifying a node (65,536 nodes) and 48 bits for address within the node (256 terabytes). A node can contain many processors and/or memory. The SCI standard defines a packet switched network. === Topologies === SCI can be used to build systems with different types of switching topologies from centralized to fully distributed switching: With a central switch, each node is connected to the switch with a ringlet (in this case a two-node ring). In distributed switching systems, each node can be connected to a ring of arbitrary length and either all or some of the nodes can be connected to two or more rings. The most common way to describe these multi-dimensional topologies is k-ary n-cubes (or tori). The SCI standard specification mentions several such topologies as examples. The 2-D torus is a combination of rings in two dimensions. Switching between the two dimensions requires a small switching capability in the node. This can be expanded to three or more dimensions. The concept of folding rings can also be applied to the Torus topologies to avoid any long connection segments. === Transactions === SCI sends information in packets. Each packet consists of an unbroken sequence of 16-bit symbols. The symbol is accompanied by a flag bit. A transition of the flag bit from 0 to 1 indicates the start of a packet. A transition from 1 to 0 occurs 1 (for echoes) or 4 symbols before the packet end. A packet contains a header with address command and status information, payload (from 0 through optional lengths of data) and a CRC check symbol. The first symbol in the packet header contains the destination node address. If the address is not within the domain handled by the receiving node, the packet is passed to the output through the bypass FIFO. In the other case, the packet is fed to a receive queue and may be transferred to a ring in another dimension. All packets are marked when they pass the scrubber (a node is established as scrubber when the ring is initialized). Packets without a valid destination address will be removed when passing the scrubber for the second time to avoid filling the ring with packets that would otherwise circulate indefinitely. === Cache coherence === Cache coherence ensures data consistency in multiprocessor systems. The simplest form applied in earlier systems was based on clearing the cache contents between context switches and disabling the cache for data that were shared between two or more processors. These methods were feasible when the performance difference between the cache and memory were less than one order of magnitude. Modern processors with caches that are more than two orders of magnitude faster than main memory would not perform anywhere near optimal without more sophisticated methods for data consistency. Bus based systems use eavesdropping (snooping) methods since buses are inherently broadcast. Modern systems with point-to point links use broadcast methods with snoop filter options to improve performance. Since broadcast and eavesdropping are inherently non-scalable, these are not used in SCI. Instead, SCI uses a distributed directory-based cache coherence protocol with a linked list of nodes containing processors that share a particular cache line. Each node holds a directory for the main memory of the node with a tag for each line of memory (same line length as the cache line). The memory tag holds a pointer to the head of the linked list and a state code for the line (three states – home, fresh, gone). Associated with each node is also a cache for holding remote data with a directory containing forward and backward pointers to nodes in the linked list sharing the cache line. The tag for the cache has seven states (invalid, only fresh, head fresh, only dirty, head dirty, mid valid, tail valid). The distributed directory is scalable. The overhead for the directory based cache coherence is a constant percentage of the node’s memory and cache. This percentage is in the order of 4% for the memory and 7% for the cache. == Legacy == SCI is a standard for connecting the different resources within a multiprocessor computer system, and it is not as widely known to the public as for example the Ethernet family for connecting different systems. Different system vendors implemented different variants of SCI for their internal system infrastructure. These different implementations interface to very intricate mechanisms in processors and memory systems and each vendor has to preserve some degrees of

Procreate (software)

Procreate is a raster graphics editor app for digital painting developed and published by the Australian company Savage Interactive for iOS and iPadOS. It was launched on the App Store in 2011. == Versions == === Procreate === Procreate for iPad was first released in 2011 by the Tasmanian software company Savage Interactive. In June 2013, Savage launched Procreate 2 in conjunction with iOS 7, adding new features such as higher resolution capabilities and more brush options. In 2016, Procreate became one of the top ten best-selling iPad apps on the App Store. In 2018, Procreate became the overall best selling iPad app. With iOS 26, Procreate adapted Liquid Glass into its software. As of March 2026, the most recent version of Procreate for the iPad is 5.4.9. === Procreate Pocket === Procreate Pocket was released to the App Store in December 2014. In 2018, Savage launched Procreate Pocket 2.0 to the App Store. In December 2018, Procreate Pocket received Apple's "App of the Year" award. As of September 2025, the most recent version of Procreate Pocket (for the iPhone) is 4.0.15. === Procreate Dreams === Procreate Dreams, their more recent app focused on 2D animation, was released on the App Store on November 22, 2023. While the application is commended for its intuitive interface and accessibility, some reviewers have noted that it may lack some key animations features, such as reference layers. In June 2024, Procreate Dreams received the 2024 Apple Design Award for Innovation. In December 2025, Savage Interactive released Procreate Dreams 2, a long awaited update and redesign to Procreate Dreams. == Features == The current versions of Procreate use Valkyrie, a proprietary graphics engine to allow customisable brush options and importing brushes from Adobe Photoshop. Procreate offers known features like layers, masks, and blending mode. Its biggest standout compared to other professional drawing software is its simple UI and comparatively easy learning curve. The app also allows for animation. Savage expanded upon Procreate's animation features with a companion app dedicated to 2D animation called Procreate Dreams, released in November 2023. On August 2024, Procreate announced that it would not be incorporating generative artificial intelligence into its software. Savage offers a free internet forum called Procreate Discussions in which users can ask for help, suggest ideas, and share user-generated content on the marketplace or the resources board. == Notable users == Concept artist Doug Chiang creates robot, vehicle, and creature designs for Star Wars in Procreate. Professional artists have also used Procreate to create the posters for Stranger Things, Logan, and Blade Runner 2049, as well as several covers for The New Yorker. It has also been professionally adopted at Marvel Comics, DC Comics, Disney Animation, and Pixar.

Bus encryption

Bus encryption is the use of encrypted program instructions on a data bus in a computer that includes a secure cryptoprocessor for executing the encrypted instructions. Bus encryption is used primarily in electronic systems that require high security, such as automated teller machines, TV set-top boxes, and secure data communication devices such as two-way digital radios. Bus encryption can also mean encrypted data transmission on a data bus from one processor to another processor. For example, from the CPU to a GPU which does not require input of encrypted instructions. Such bus encryption is used by Windows Vista and newer Microsoft operating systems to protect certificates, BIOS, passwords, and program authenticity. PVP-UAB (Protected Video Path) provides bus encryption of premium video content in PCs as it passes over the PCIe bus to graphics cards to enforce digital rights management. The need for bus encryption arises when multiple people have access to the internal circuitry of an electronic system, either because they service and repair such systems, stock spare components for the systems, own the system, steal the system, or find a lost or abandoned system. Bus encryption is necessary not only to prevent tampering of encrypted instructions that may be easily discovered on a data bus or during data transmission, but also to prevent discovery of decrypted instructions that may reveal security weaknesses that an intruder can exploit. In TV set-top boxes, it is necessary to download program instructions periodically to customer's units to provide new features and to fix bugs. These new instructions are encrypted before transmission, but must also remain secure on data buses and during execution to prevent the manufacture of unauthorized cable TV boxes. This can be accomplished by secure crypto-processors that read encrypted instructions on the data bus from external data memory, decrypt the instructions in the cryptoprocessor, and execute the instructions in the same cryptoprocessor.