Digistar is the first computer graphics-based planetarium projection and content system. It was designed by Evans & Sutherland and released in 1983. The technology originally focused on accurate and high quality display of stars, including for the first time showing stars from points of view other than Earth's surface, travelling through the stars, and accurately showing celestial bodies from different times in the past and future. Beginning with the Digistar 3 the system now projects full-dome video. == Projector == Unlike modern full-dome systems, which use LCD, DLP, SXRD, or laser projection technology, the Digistar projection system was designed for projecting bright pinpoints of light representing stars. This was accomplished using a calligraphic display, a form of vector graphics, rather than raster graphics. The heart of the Digistar projector is a large cathode-ray tube (CRT). A phosphor plate is mounted atop the tube, and light is then dispersed by a large lens with a 160 degree field of view to cover the planetarium dome. The original lens bore the inscription: "August 1979 mfg. by Lincoln Optical Corp., L.A., CA for Evans and Sutherland Computer Corp., SLC, UT, Digital planetarium CRT projection lens, 43mm, f2.8, 160 degree field of view". The coordinates of the stars and wire-frame models to be displayed by the projector were stored in computer RAM in a display list. The display would read each set of coordinates in turn and drive the CRT's electron beam directly to those coordinates. If the electron beam was enabled while being moved a line would be painted on the phosphor plate. Otherwise, the electron beam would be enabled once at its destination and a star would be painted. Once all coordinates in the display list had been processed, the display would repeat from the top of the display list. Thus, the shorter the display list the more frequently the electron beam would refresh the charge on a given point on the phosphor plate, making the projection of the points brighter. In this way, the stars projected by Digistar were substantially brighter than could be achieved using a raster display, which has to touch every point on the phosphor plate before repeating. Likewise, the calligraphic technology allowed Digistar to have a darker black-level than full-dome projectors, since the portions of the phosphor plate representing dark sky were never hit by the electron beam. As it is only one tube, with no pixelated color filter screen, the Digistar projector is monochromatic. The Digistar projects a bright, phosphorescent green, though many (including both visitors and planetarians) report they cannot distinguish between this green and white. Additionally, unlike a raster display, the calligraphic display is not discretized into pixels, so the displayed stars were a more realistic single spot of light, without the blocky or ropy artifacts that are hard to avoid with raster graphics. Due to the use of vector graphics, as opposed to raster imaging, the Digistar does not have the resolution issues that many full-dome systems have. Thanks to this, and the brightness of the CRT, only one projector is needed to project on the entire dome, whereas most full-dome systems require up to six raster projectors, depending on dome size. The projector in the original Digistar was housed in a square pyramid-shaped sheathing. When powered on, the four sides at the tip of the pyramid would recede into the housing, exposing the lens and appearing as a cut-off pyramid. As Digistar II was being developed, many planetaria were sold Digistar LEA projectors. The LEA, called Digistar 1.5 by many users, was effectively a prototype of the D2 projector, compatible with Digistar and upgradable to Digistar II. There are no significant differences in performance between the LEA and the true D2. == History == Digistar was the brainchild of Stephen McAllister and Brent Watson, both of whom were long-time amateur astronomers and computer graphics engineers. In 1977, E&S had been consulting with Johnson Space Center regarding training simulators for astronauts. McAllister had been writing proof-of-concept software for this consultation and in summer 1977 entered the data for 400 bright stars and wrote the software to display them. Steve and Brent both originally saw the system's purpose as celestial navigation training. Brent, who had until recently worked at Hansen planetarium, asked his planetarium coworkers what they thought of a potential digital planetarium system, and then Steve and Brent both targeted the system toward planetaria. The primary goal of the planetarium system was to use computer graphics to overcome the limitation of traditional star ball technology that only allowed display of star fields from the point of view of Earth's surface. By using computer graphics the stars could be displayed from viewpoints in space, including simulating the appearance of space flight. Likewise, planets and moons within the Solar System could be displayed accurately for any time in history, from any point of view. The system used the location of real stars from the Yale Bright Star Catalogue, as well as random stars. A laboratory prototype of Digistar was used to generate the star fields and tactical displays in the 1982 science fiction film Star Trek II: The Wrath of Khan. Filming was done directly from the Digistar display in the lab. ILM projected the effort would take two weeks, but in fact it took from late November 1981 until mid-February 1982. The last shot recorded was what became the first entirely computer generated feature film sequence. It was the opening scene of the film, a rotating forward translation through a star field that lasted 3.5 minutes. It was recorded in one take, at a rate of one frame every 3.5 seconds, taking four hours for the shoot. The Digistar team members are credited in the film. After prototyping in labs at Evans and Sutherland the team repeatedly used Salt Lake City's Hansen planetarium to beta test the system at the planetarium at night. The Digistar team performed one week of shows at the planetarium as a fund raiser to benefit the planetarium. The company also later gave the planetarium an improved prototype Digistar to replace "Jake", the planetarium's aging Spitz planetarium projector. The first customer installation was to the newly constructed Universe Planetarium at the Science Museum of Virginia in 1983, the largest planetarium dome in the world at the time, for $595,000. By September 1986 there were four installed Digistars. Even at this point the long-term success of the product was very much in doubt, but as of 2019 Digistar has an installed base of over 550 planetaria. === Versions === Digistar (1983) Digistar II (1995) Digistar 3 (2002) Digistar 4 (2010?) Digistar 5 (2012) Digistar 6 (2016) Digistar 7 (2021) == Hardware == Digistar was driven by a VAX-11/780 minicomputer, with custom graphics hardware related to the E&S Picture System 2. Later versions of Digistar 1 used a DEC MicroVAX 2, driving a custom version of a PS/300. The original Digistar and Digistar 2 had a physical control panel that was used for running the star shows. This control panel was approximately 3' x 4' and contained a keyboard, a 6 DOF joystick, and a large array of back-lit buttons. One button that was used for moving the viewpoint forward in space was labeled "Boldly Go". Later iterations of Digistar replaced the physical control panel with a common graphical user interface. Digistar 3 was the first Digistar system to offer full-dome video in 2002, using six projectors. Digistar 4 was able to cover the dome using only two projectors. == System limitations == Though technologically advanced in its day, and the closest system to true full-dome video at the time of its release, the original Digistar and Digistar 2 are limited to only projecting dots and lines—meaning only wireframe models can be projected. To compensate for this, the projector is capable of defocusing specific models, blurring lines and dots together. An example of this is in the Digistar 2's built-in Milky Way model. The model is a circle of parallel lines that, when defocused, appear as the continuous band of the Milky Way across the sky. On more complex models, especially three-dimensional ones, brightness and details may be lost in this process, so it is not useful in all situations. The Digistar and Digistar 2 also suffer focus limitations. Because they use a single lens to cover the entire dome, it is difficult to gain perfect focus across the dome. Coupled with this, stars greater than a certain brightness are "multihit" points, meaning the projector draws two dots at the given position to accommodate the brightness of the star. Errors in the projector can lead the second dot to be slightly out-of-place with the first one. These two issues together, along with other issues that can occur within the projector's focus system, give the stars a blobby look. Some p
Random feature
Random features (RF) are a technique used in machine learning to approximate kernel methods, introduced by Ali Rahimi and Ben Recht in their 2007 paper "Random Features for Large-Scale Kernel Machines", and extended by. RF uses a Monte Carlo approximation to kernel functions by randomly sampled feature maps. It is used for datasets that are too large for traditional kernel methods like support vector machine, kernel ridge regression, and gaussian process. == Mathematics == === Kernel method === Given a feature map ϕ : R d → V {\textstyle \phi :\mathbb {R} ^{d}\to V} , where V {\textstyle V} is a Hilbert space (more specifically, a reproducing kernel Hilbert space), the kernel trick replaces inner products in feature space ⟨ ϕ ( x i ) , ϕ ( x j ) ⟩ V {\displaystyle \langle \phi (x_{i}),\phi (x_{j})\rangle _{V}} by a kernel function k ( x i , x j ) : R d × R d → R {\displaystyle k(x_{i},x_{j}):\mathbb {R} ^{d}\times \mathbb {R} ^{d}\to \mathbb {R} } Kernel methods replaces linear operations in high-dimensional space by operations on the kernel matrix: K X := [ k ( x i , x j ) ] i , j ∈ 1 : N {\displaystyle K_{X}:=[k(x_{i},x_{j})]_{i,j\in 1:N}} where N {\textstyle N} is the number of data points. === Random kernel method === The problem with kernel methods is that the kernel matrix K X {\textstyle K_{X}} has size N × N {\textstyle N\times N} . This becomes computationally infeasible when N {\textstyle N} reaches the order of a million. The random kernel method replaces the kernel function k {\textstyle k} by an inner product in low-dimensional feature space R D {\textstyle \mathbb {R} ^{D}} : k ( x , y ) ≈ ⟨ z ( x ) , z ( y ) ⟩ {\displaystyle k(x,y)\approx \langle z(x),z(y)\rangle } where z {\textstyle z} is a randomly sampled feature map z : R d → R D {\textstyle z:\mathbb {R} ^{d}\to \mathbb {R} ^{D}} . This converts kernel linear regression into linear regression in feature space, kernel SVM into SVM in feature space, etc. Since we have K X ≈ Z X T Z X {\displaystyle K_{X}\approx Z_{X}^{T}Z_{X}} where Z X = [ z ( x 1 ) , … , z ( x N ) ] {\displaystyle Z_{X}=[z(x_{1}),\dots ,z(x_{N})]} , these methods no longer involve matrices of size O ( N 2 ) {\textstyle O(N^{2})} , but only random feature matrices of size O ( D N ) {\textstyle O(DN)} . == Random Fourier feature == === Radial basis function kernel === The radial basis function (RBF) kernel on two samples x i , x j ∈ R d {\displaystyle x_{i},x_{j}\in \mathbb {R} ^{d}} is defined as k ( x i , x j ) = exp ( − ‖ x i − x j ‖ 2 2 σ 2 ) {\displaystyle k(x_{i},x_{j})=\exp \left(-{\frac {\|x_{i}-x_{j}\|^{2}}{2\sigma ^{2}}}\right)} where ‖ x i − x j ‖ 2 {\displaystyle \|x_{i}-x_{j}\|^{2}} is the squared Euclidean distance and σ {\displaystyle \sigma } is a free parameter defining the shape of the kernel. It can be approximated by a random Fourier feature map z : R d → R 2 D {\displaystyle z:\mathbb {R} ^{d}\to \mathbb {R} ^{2D}} : z ( x ) := 1 D [ cos ⟨ ω 1 , x ⟩ , sin ⟨ ω 1 , x ⟩ , … , cos ⟨ ω D , x ⟩ , sin ⟨ ω D , x ⟩ ] T {\displaystyle z(x):={\frac {1}{\sqrt {D}}}[\cos \langle \omega _{1},x\rangle ,\sin \langle \omega _{1},x\rangle ,\ldots ,\cos \langle \omega _{D},x\rangle ,\sin \langle \omega _{D},x\rangle ]^{T}} where ω 1 , . . . , ω D {\displaystyle \omega _{1},...,\omega _{D}} are IID samples from the multidimensional normal distribution N ( 0 , σ − 2 I ) {\displaystyle N(0,\sigma ^{-2}I)} . Since cos , sin {\displaystyle \cos ,\sin } are bounded, there is a stronger convergence guarantee by Hoeffding's inequality. === Random Fourier features === By Bochner's theorem, the above construction can be generalized to arbitrary positive definite shift-invariant kernel k ( x , y ) = k ( x − y ) {\displaystyle k(x,y)=k(x-y)} . Define its Fourier transform p ( ω ) = 1 2 π ∫ R d e − j ⟨ ω , Δ ⟩ k ( Δ ) d Δ {\displaystyle p(\omega )={\frac {1}{2\pi }}\int _{\mathbb {R} ^{d}}e^{-j\langle \omega ,\Delta \rangle }k(\Delta )d\Delta } then ω 1 , . . . , ω D {\displaystyle \omega _{1},...,\omega _{D}} are sampled IID from the probability distribution with probability density p {\displaystyle p} . This applies for other kernels like the Laplace kernel and the Cauchy kernel. === Neural network interpretation === Given a random Fourier feature map z {\displaystyle z} , training the feature on a dataset by featurized linear regression is equivalent to fitting complex parameters θ 1 , … , θ D ∈ C {\displaystyle \theta _{1},\dots ,\theta _{D}\in \mathbb {C} } such that f θ ( x ) = R e ( ∑ k θ k e i ⟨ ω k , x ⟩ ) {\displaystyle f_{\theta }(x)=\mathrm {Re} \left(\sum _{k}\theta _{k}e^{i\langle \omega _{k},x\rangle }\right)} which is a neural network with a single hidden layer, with activation function t ↦ e i t {\displaystyle t\mapsto e^{it}} , zero bias, and the parameters in the first layer frozen. In the overparameterized case, when 2 D ≥ N {\displaystyle 2D\geq N} , the network linearly interpolates the dataset { ( x i , y i ) } i ∈ 1 : N {\displaystyle \{(x_{i},y_{i})\}_{i\in 1:N}} , and the network parameters is the least-norm solution: θ ^ = arg min θ ∈ C D , f θ ( x k ) = y k ∀ k ∈ 1 : N ‖ θ ‖ {\displaystyle {\hat {\theta }}=\arg \min _{\theta \in \mathbb {C} ^{D},f_{\theta }(x_{k})=y_{k}\forall k\in 1:N}\|\theta \|} At the limit of D → ∞ {\displaystyle D\to \infty } , the L2 norm ‖ θ ^ ‖ → ‖ f K ‖ H {\displaystyle \|{\hat {\theta }}\|\to \|f_{K}\|_{H}} where f K {\displaystyle f_{K}} is the interpolating function obtained by the kernel regression with the original kernel, and ‖ ⋅ ‖ H {\displaystyle \|\cdot \|_{H}} is the norm in the reproducing kernel Hilbert space for the kernel. == Other examples == === Random binning features === A random binning features map partitions the input space using randomly shifted grids at randomly chosen resolutions and assigns to an input point a binary bit string that corresponds to the bins in which it falls. The grids are constructed so that the probability that two points x i , x j ∈ R d {\displaystyle x_{i},x_{j}\in \mathbb {R} ^{d}} are assigned to the same bin is proportional to K ( x i , x j ) {\displaystyle K(x_{i},x_{j})} . The inner product between a pair of transformed points is proportional to the number of times the two points are binned together, and is therefore an unbiased estimate of K ( x i , x j ) {\displaystyle K(x_{i},x_{j})} . Since this mapping is not smooth and uses the proximity between input points, Random Binning Features works well for approximating kernels that depend only on the L 1 {\displaystyle L_{1}} distance between datapoints. === Orthogonal random features === Orthogonal random features uses a random orthogonal matrix instead of a random Fourier matrix. == Historical context == In NIPS 2006, deep learning had just become competitive with linear models like PCA and linear SVMs for large datasets, and people speculated about whether it could compete with kernel SVMs. However, there was no way to train kernel SVM on large datasets. The two authors developed the random feature method to train those. It was then found that the O ( 1 / D ) {\displaystyle O(1/D)} variance bound did not match practice: the variance bound predicts that approximation to within 0.01 {\displaystyle 0.01} requires D ∼ 10 4 {\displaystyle D\sim 10^{4}} , but in practice required only ∼ 10 2 {\displaystyle \sim 10^{2}} . Attempting to discover what caused this led to the subsequent two papers.
Cloud-based quantum computing
Cloud-based quantum computing refers to the remote access of quantum computing resources—such as quantum emulators, simulators, or processors—via the internet. Cloud access enables users to develop, test, and execute quantum algorithms without the need for direct interaction with specialized hardware, facilitating broader participation in quantum software development and experimentation. In 2016, IBM launched the IBM Quantum Experience, one of the first publicly accessible quantum processors connected to the cloud. In early 2017, researchers at Rigetti Computing demonstrated programmable quantum cloud access through their software platform Forest, which included the pyQuil Python library. Since the early-2020s, cloud-based quantum computing has grown significantly, with multiple providers offering access to a variety of quantum hardware modalities, including superconducting qubits, trapped ions, neutral atoms, and photonic systems. Major platforms such as Amazon Braket, Azure Quantum, and qBraid aggregate quantum devices from hardware developers like IonQ, Rigetti Computing, QuEra, Pasqal, Oxford Quantum Circuits, and IBM Quantum. These platforms provide unified interfaces for users to write and execute quantum algorithms across diverse backends, often supporting open-source SDKs such as Qiskit, Cirq, and PennyLane. The proliferation of cloud-based access has played a key role in accelerating quantum education, algorithm research, and early-stage application development by lowering the barrier to experimentation with real quantum hardware. Cloud-based quantum computing has expanded access to quantum hardware and tools beyond traditional research laboratories. These platforms support educational initiatives, algorithm development, and early-stage commercial applications. == Applications == Cloud-based quantum computing is used across education, research, and software development, offering remote access to quantum systems without the need for on-site infrastructure. === Education === Quantum cloud platforms have become valuable tools in education, allowing students and instructors to engage with real quantum processors through user-friendly interfaces. Educators use these platforms to teach foundational concepts in quantum mechanics and quantum computing, as well as to demonstrate and implement quantum algorithms in a classroom or laboratory setting. === Scientific Research === Cloud-based access to quantum hardware has enabled researchers to conduct experiments in quantum information, test quantum algorithms, and compare quantum hardware platforms. Experiments such as testing Bell's theorem or evaluating quantum teleportation protocols have been performed on publicly available quantum processors. === Software Development and Prototyping === Developers use cloud-based platforms to prototype quantum software applications across fields such as optimization, machine learning, and chemistry. These platforms offer SDKs and APIs that integrate classical and quantum workflows, enabling experimentation with quantum algorithms in real-world or simulated environments. === Public Engagement and Games === Quantum cloud tools have also been used to create educational games and interactive applications aimed at increasing public understanding of quantum concepts. These efforts help bridge the gap between theoretical content and intuitive learning. == Existing platforms == qBraid Lab by qBraid is a cloud-based platform for quantum computing. It provides software tools for researchers and developers in quantum, as well as access to quantum hardware. qBraid provides cloud based access to Microsoft Azure Quantum and Amazon Braket devices including IQM, QuEra, Pasqal, Rigetti, IonQ, QIR simulators, Amazon Braket simulators, and the NEC Vector Annealer, as of August 2025. qBraid's base version is free, where unlimited hardware and simulator access is available with the purchase of credits. Quandela Cloud by Quandela is the platform to access first cloud-accessible European photonic quantum computer. The computer is interfaced using the Perceval scripting language, with tutorials and documentation available online for free. Xanadu Quantum Cloud by Xanadu is a platform with cloud-based access to three fully programmable photonic quantum computers. Forest by Rigetti Computing is a tool suite for cloud-based quantum computing. It includes a programming language, development tools and example algorithms. LIQUi> by Microsoft is a software architecture and tool suite for quantum computing. It includes a programming language, example optimization and scheduling algorithms, and quantum simulators. Q#, a quantum programming language by Microsoft on the .NET Framework seen as a successor to LIQUi|>. IBM Quantum Platform by IBM, providing access to quantum hardware as well as HPC simulators. These can be accessed programmatically using the Python-based Qiskit framework, or via graphical interface with the IBM Q Experience GUI. Both are based on the OpenQASM standard for representing quantum operations. There is also a tutorial and online community. Quantum in the Cloud by The University of Bristol, which consists of a quantum simulator and a four qubit optical quantum system. Quantum Playground by Google is an educational resource which features a simulator with a simple interface, and a scripting language and 3D quantum state visualization. Quantum in the Cloud is an experimental quantum cloud platform for access to a four-qubit nuclear magnetic resonance-NMRCloudQ computer, managed by Tsinghua University. Quantum Inspire by Qutech is the first platform in Europe providing cloud-based quantum computing to two hardware chips. Next to a 5-qubit transmon processor, Quantum Inspire is the first platform in the world to provide online access to a fully programmable 2-qubit electron spin quantum processor. Amazon Braket is a cloud-based quantum computing platform hosted by AWS which, as of June 2025, provides access to quantum computers built by IonQ, Rigetti, IQM, and QuEra. Braket also provides a quantum algorithm development environment and simulator. Forge by QC Ware is a cloud-based quantum computing platform that provides access to D-Wave hardware, as well as Google and IBM simulators. The platform offers a 30-day free trial, including one minute of quantum computing time. Quantum-as-a-Service by Scaleway is a cloud-based platform created in 2022 to access to real quantum hardware from IQM Quantum Computers, Alpine Quantum Technologies, Quandela and Pasqal. It also include access to GPU-powered emulators such as Aer, Qsim and Quandela proprietary emulation.
Enonic XP
Enonic XP is a free and open-source content platform. Developed by the Norwegian software company Enonic, the platform can be used to build websites, progressive web applications, or web-based APIs. Enonic XP uses an application framework for coding server logic with JavaScript, and has no need for SQL as it ships with an integrated content repository. The CMS is fully decoupled, meaning developers can create traditional websites and landing pages, or use XP in headless mode, that is without the presentation layer, for loading editorial content onto any device or client. Enonic is used by major organizations in Norway, including the national postal service Norway Post, the insurance company Gjensidige, the Norwegian Labour and Welfare Administration, and all the top football clubs in the national football league for men, Eliteserien. == Overview == Enonic XP ships with the content management system (CMS) Content Studio. This includes a visual drag and drop editor, a landing page editor, support for multi-site and multi-language, media and structured content, advanced image editing, responsive user interface, permissions and roles management, revision and version control, and bulk publishing. Integrations and applications can be directly installed via the "Applications" section in XP, where the platform finds apps approved in the official Enonic Market. There are no third-party databases in Enonic XP. Instead, the developers have built a distributed storage repository, avoiding the need to index content. The system brings together capabilities from Filesystem, NoSQL, document stores, and search in the storage technology, which automatically indexes everything put into the storage. Enonic XP supports deployment of server side JavaScript. The open-source framework runs on top of a JVM (Java virtual machine), and allows developers to run the same code in the browser and on the server, thus enabling them to employ JavaScript. While running on the Java virtual machine, Enonic XP can be deployed on most infrastructures. The dependency on a third-party application server to deploy code has been removed, as the platform is an application server by default. A developer can for instance insert his own modules and code straight into the system while it is running. JavaScript unifies all the technical elements, and Enonic XP features a MVC framework where everything on the back-end can be coded with server-side JavaScript. The Enonic platform can use any template engine. === Progressive web apps === Another feature of Enonic XP is the possibility for developers to create progressive web apps (PWA). A PWA is a web application that is a regular web page or website, but can appear to the user like a mobile application. === Headless CMS and integrations === Enonic XP is headless, which means it separates content and presentation. The platform supports GraphQL, provides several default APIs, and allows for building custom APIs through the Guillotine starter kit. Consequently, Enonic supports modern front-end frameworks, and offers integrations with e.g. Next.js and React. == History == Enonic AS was founded in 2000 by Morten Øien Eriksen and Thomas Sigdestad. The software company specialized in building services and solutions, including a content management system known as "Vertical Site", then "Enonic CMS". Being aware that they had application, database, and website teams working on separate silos toward the same goal, Enonic sought to combine the different elements into a single software. The resulting application platform Enonic XP, first released in 2015, includes a CMS as an optional surface layer. In March 2020, Enonic XP was ranked by SoftwareReviews, a division of Info-Tech Research Group, a Canadian IT research and analyst firm, as the "Leader" in Web Experience Management. The ranking is based on user reviews, and is featured in SoftwareReviews‘ Digital Experience Data Quadrant Report, a comprehensive evaluation and ranking of leading Web Experience Management vendors. Enonic was also ranked first in 2021 and 2022. === Release history === Enonic XP assumed the mantle from the previous content management system Enonic CMS, and thus began with "version 5.0.0." The following list only contains major releases. == Development and support == Enonic offers a user and developer community consisting of a forum, support system with tickets, documentation, codex, learning and training center with certifications, and various community groups. Writing about the support system, Mike Johnston of CMS Critic notes that "enterprise customers obviously get access to a higher level of personalized support, where the Enonic support team can respond as fast as two hours." The support system is divided in three levels: silver, gold and platinum—from next day business support to 24/7 support. As Enonic XP is open-source, known vulnerabilities, bugs and issues are listed on GitHub.
NumPy
NumPy (pronounced NUM-py) is a library for the Python programming language, adding support for large, multi-dimensional arrays and matrices, along with a large collection of high-level mathematical functions to operate on these arrays. The predecessor of NumPy, Numeric, was originally created by Jim Hugunin with contributions from several other developers. In 2005, Travis Oliphant created NumPy by incorporating features of the competing Numarray into Numeric, with extensive modifications. NumPy is open-source software and has many contributors. NumPy is fiscally sponsored by NumFOCUS. == History == === matrix-sig === The Python programming language was not originally designed for numerical computing, but attracted the attention of the scientific and engineering community early on. In 1995 the special interest group (SIG) matrix-sig was founded with the aim of defining an array computing package; among its members was Python designer and maintainer Guido van Rossum, who extended Python's syntax (in particular the indexing syntax) to make array computing easier. === Numeric === An implementation of a matrix package was completed by Jim Fulton, then expanded to support multi-dimensional arrays by Jim Hugunin and called Numeric (also variously known as the "Numerical Python extensions" or "NumPy"), with influences from the APL family of languages, Basis, MATLAB, FORTRAN, S and S+, and others. Hugunin, a graduate student at the Massachusetts Institute of Technology (MIT), joined the Corporation for National Research Initiatives (CNRI) in 1997 to work on JPython, leaving Paul Dubois of Lawrence Livermore National Laboratory (LLNL) to take over as maintainer. Other early contributors include David Ascher, Konrad Hinsen and Travis Oliphant. === Numarray === A new package called Numarray was written as a more flexible replacement for Numeric. Like Numeric, it too is now deprecated. Numarray had faster operations for large arrays, but was slower than Numeric on small ones, so for a time both packages were used in parallel for different use cases. The last version of Numeric (v24.2) was released on 11 November 2005, while the last version of numarray (v1.5.2) was released on 24 August 2006. There was a desire to get Numeric into the Python standard library, but Guido van Rossum decided that the code was not maintainable in its state then. === NumPy === In early 2005, NumPy developer Travis Oliphant wanted to unify the community around a single array package and ported Numarray's features to Numeric, releasing the result as NumPy 1.0 in 2006. This new project was part of SciPy. To avoid installing the large SciPy package just to get an array object, this new package was separated and called NumPy. Support for Python 3 was added in 2011 with NumPy version 1.5.0. In 2011, PyPy started development on an implementation of the NumPy API for PyPy. As of 2023, it is not yet fully compatible with NumPy. == Features == NumPy targets the CPython reference implementation of Python, which is a non-optimizing bytecode interpreter. Mathematical algorithms written for this version of Python often run much slower than compiled equivalents due to the absence of compiler optimization. NumPy addresses the slowness problem partly by providing multidimensional arrays and functions and operators that operate efficiently on arrays; using these requires rewriting some code, mostly inner loops, using NumPy. Using NumPy in Python gives functionality comparable to MATLAB since they are both interpreted, and they both allow the user to write fast programs as long as most operations work on arrays or matrices instead of scalars. In comparison, MATLAB boasts a large number of additional toolboxes, notably Simulink, whereas NumPy is intrinsically integrated with Python, a more modern and complete programming language. Moreover, complementary Python packages are available; SciPy is a library that adds more MATLAB-like functionality and Matplotlib is a plotting package that provides MATLAB-like plotting functionality. Although MATLAB can perform sparse matrix operations, NumPy alone cannot perform such operations and requires the use of the scipy.sparse library. Internally, both MATLAB and NumPy rely on BLAS and LAPACK for efficient linear algebra computations. Python bindings of the widely used computer vision library OpenCV utilize NumPy arrays to store and operate on data. Since images with multiple channels are simply represented as three-dimensional arrays, indexing, slicing or masking with other arrays are very efficient ways to access specific pixels of an image. The NumPy array as universal data structure in OpenCV for images, extracted feature points, filter kernels and many more vastly simplifies the programming workflow and debugging. Importantly, many NumPy operations release the global interpreter lock, which allows for multithreaded processing. NumPy also provides a C API, which allows Python code to interoperate with external libraries written in low-level languages. === The ndarray data structure === The core functionality of NumPy is its "ndarray", for n-dimensional array, data structure. These arrays are strided views on memory. In contrast to Python's built-in list data structure, these arrays are homogeneously typed: all elements of a single array must be of the same type. Such arrays can also be views into memory buffers allocated by C/C++, Python, and Fortran extensions to the CPython interpreter without the need to copy data around, giving a degree of compatibility with existing numerical libraries. This functionality is exploited by the SciPy package, which wraps a number of such libraries (notably BLAS and LAPACK). NumPy has built-in support for memory-mapped ndarrays. === Limitations === Inserting or appending entries to an array is not as trivially possible as it is with Python's lists. The np.pad(...) routine to extend arrays actually creates new arrays of the desired shape and padding values, copies the given array into the new one and returns it. NumPy's np.concatenate([a1,a2]) operation does not actually link the two arrays but returns a new one, filled with the entries from both given arrays in sequence. Reshaping the dimensionality of an array with np.reshape(...) is only possible as long as the number of elements in the array does not change. These circumstances originate from the fact that NumPy's arrays must be views on contiguous memory buffers. Algorithms that are not expressible as a vectorized operation will typically run slowly because they must be implemented in "pure Python", while vectorization may increase memory complexity of some operations from constant to linear, because temporary arrays must be created that are as large as the inputs. Runtime compilation of numerical code has been implemented by several groups to avoid these problems; open source solutions that interoperate with NumPy include numexpr and Numba. Cython and Pythran are static-compiling alternatives to these. Many modern large-scale scientific computing applications have requirements that exceed the capabilities of the NumPy arrays. For example, NumPy arrays are usually loaded into a computer's memory, which might have insufficient capacity for the analysis of large datasets. Further, NumPy operations are executed on a single CPU. However, many linear algebra operations can be accelerated by executing them on clusters of CPUs or of specialized hardware, such as GPUs and TPUs, which many deep learning applications rely on. As a result, several alternative array implementations have arisen in the scientific python ecosystem over the recent years, such as Dask for distributed arrays and TensorFlow or JAX for computations on GPUs. Because of its popularity, these often implement a subset of NumPy's API or mimic it, so that users can change their array implementation with minimal changes to their code required. A library named CuPy, accelerated by Nvidia's CUDA framework, has also shown potential for faster computing, being a 'drop-in replacement' of NumPy. == Examples == NumPy is conventionally imported as np. === Basic operations === === Universal functions === === Linear algebra === === Multidimensional arrays === === Incorporation with OpenCV === === Nearest-neighbor search === Functional Python and vectorized NumPy version. === F2PY === Quickly wrap native code for faster scripts.
Robot learning
Robot learning is a research field at the intersection of machine learning and robotics. It studies techniques allowing a robot to acquire novel skills or adapt to its environment through learning algorithms. The embodiment of the robot, situated in a physical embedding, provides at the same time specific difficulties (e.g. high-dimensionality, real time constraints for collecting data and learning) and opportunities for guiding the learning process (e.g. sensorimotor synergies, motor primitives). Example of skills that are targeted by learning algorithms include sensorimotor skills such as locomotion, grasping, active object categorization, as well as interactive skills such as joint manipulation of an object with a human peer, and linguistic skills such as the grounded and situated meaning of human language. Learning can happen either through autonomous self-exploration or through guidance from a human teacher, like for example in robot learning by imitation. Robot learning can be closely related to adaptive control, reinforcement learning as well as developmental robotics which considers the problem of autonomous lifelong acquisition of repertoires of skills. While machine learning is frequently used by computer vision algorithms employed in the context of robotics, these applications are usually not referred to as "robot learning". == Imitation learning == Many research groups are developing techniques where robots learn by imitating. This includes various techniques for learning from demonstration (sometimes also referred to as "programming by demonstration") and observational learning. == Sharing learned skills and knowledge == In Tellex's "Million Object Challenge", the goal is robots that learn how to spot and handle simple items and upload their data to the cloud to allow other robots to analyze and use the information. RoboBrain is a knowledge engine for robots which can be freely accessed by any device wishing to carry out a task. The database gathers new information about tasks as robots perform them, by searching the Internet, interpreting natural language text, images, and videos, object recognition as well as interaction. The project is led by Ashutosh Saxena at Stanford University. RoboEarth is a project that has been described as a "World Wide Web for robots" − it is a network and database repository where robots can share information and learn from each other and a cloud for outsourcing heavy computation tasks. The project brings together researchers from five major universities in Germany, the Netherlands and Spain and is backed by the European Union. Google Research, DeepMind, and Google X have decided to allow their robots share their experiences. == Vision-language-action model == Research groups and companies are developing vision-language-action models, foundation models that allow robotic control through the combination of vision and language. Google DeepMind, Figure AI and Hugging Face are actively working on that.
Direct Graphics Access
Direct Graphics Access is a plug-in for the X display servers that allows client programs direct access to the frame buffer. Graphics hardware communicates via a chunk of memory called a frame buffer. This is an array of values that represent pixel color values on the screen. Writing the appropriate values into the frame buffer therefore allows a program to paint areas of the screen. However, as with any shared resource, problems occur when multiple programs attempt to access the same resource, as they tend to write over each other's work. In the X Window System, this is solved by having a central display server that mediates between programs that want to draw on the screen. The display server also used to perform a lot of the drawing work, allowing programs to say Draw me a circle of this radius filled with this pattern or draw this text in this font. The X server does all this work, freeing programmers from having to write their own drawing code. Another advantage of the X architecture is that it works over a network, allowing programs on one machine to display output on the screen of another. Direct Graphics Access allows direct access to the frame buffer and the X-server hands over control of the frame buffer to the client program and waits for the client to hand it back. This means that the client program has control of the whole screen, and so it is mostly used for full-screen video/games.