Computational semantics is a subfield of computational linguistics. Its goal is to elucidate the cognitive mechanisms supporting the generation and interpretation of meaning in humans. It usually involves the creation of computational models that simulate particular semantic phenomena, and the evaluation of those models against data from human participants. While computational semantics is a scientific field, it has many applications in real-world settings and substantially overlaps with Artificial Intelligence. Broadly speaking, the discipline can be subdivided into areas that mirror the internal organization of linguistics. For example, lexical semantics and frame semantics have active research communities within computational linguistics. Some popular methodologies are also strongly inspired by traditional linguistics. Most prominently, the area of distributional semantics, which underpins investigations into embeddings and the internals of Large Language Models, has roots in the work of Zellig Harris. Some traditional topics of interest in computational semantics are: construction of meaning representations, semantic underspecification, anaphora resolution, presupposition projection, and quantifier scope resolution. Methods employed usually draw from formal semantics or statistical semantics. Computational semantics has points of contact with the areas of lexical semantics (word-sense disambiguation and semantic role labeling), discourse semantics, knowledge representation and automated reasoning (in particular, automated theorem proving). Since 1999 there has been an ACL special interest group on computational semantics, SIGSEM.
Multi-scale approaches
The scale space representation of a signal obtained by Gaussian smoothing satisfies a number of special properties, scale-space axioms, which make it into a special form of multi-scale representation. There are, however, also other types of "multi-scale approaches" in the areas of computer vision, image processing and signal processing, in particular the notion of wavelets. The purpose of this article is to describe a few of these approaches: == Scale-space theory for one-dimensional signals == For one-dimensional signals, there exists quite a well-developed theory for continuous and discrete kernels that guarantee that new local extrema or zero-crossings cannot be created by a convolution operation. For continuous signals, it holds that all scale-space kernels can be decomposed into the following sets of primitive smoothing kernels: the Gaussian kernel : g ( x , t ) = 1 2 π t exp ( − x 2 / 2 t ) {\displaystyle g(x,t)={\frac {1}{\sqrt {2\pi t}}}\exp({-x^{2}/2t})} where t > 0 {\displaystyle t>0} , truncated exponential kernels (filters with one real pole in the s-plane): h ( x ) = exp ( − a x ) {\displaystyle h(x)=\exp({-ax})} if x ≥ 0 {\displaystyle x\geq 0} and 0 otherwise where a > 0 {\displaystyle a>0} h ( x ) = exp ( b x ) {\displaystyle h(x)=\exp({bx})} if x ≤ 0 {\displaystyle x\leq 0} and 0 otherwise where b > 0 {\displaystyle b>0} , translations, rescalings. For discrete signals, we can, up to trivial translations and rescalings, decompose any discrete scale-space kernel into the following primitive operations: the discrete Gaussian kernel T ( n , t ) = I n ( α t ) {\displaystyle T(n,t)=I_{n}(\alpha t)} where α , t > 0 {\displaystyle \alpha ,t>0} where I n {\displaystyle I_{n}} are the modified Bessel functions of integer order, generalized binomial kernels corresponding to linear smoothing of the form f o u t ( x ) = p f i n ( x ) + q f i n ( x − 1 ) {\displaystyle f_{out}(x)=pf_{in}(x)+qf_{in}(x-1)} where p , q > 0 {\displaystyle p,q>0} f o u t ( x ) = p f i n ( x ) + q f i n ( x + 1 ) {\displaystyle f_{out}(x)=pf_{in}(x)+qf_{in}(x+1)} where p , q > 0 {\displaystyle p,q>0} , first-order recursive filters corresponding to linear smoothing of the form f o u t ( x ) = f i n ( x ) + α f o u t ( x − 1 ) {\displaystyle f_{out}(x)=f_{in}(x)+\alpha f_{out}(x-1)} where α > 0 {\displaystyle \alpha >0} f o u t ( x ) = f i n ( x ) + β f o u t ( x + 1 ) {\displaystyle f_{out}(x)=f_{in}(x)+\beta f_{out}(x+1)} where β > 0 {\displaystyle \beta >0} , the one-sided Poisson kernel p ( n , t ) = e − t t n n ! {\displaystyle p(n,t)=e^{-t}{\frac {t^{n}}{n!}}} for n ≥ 0 {\displaystyle n\geq 0} where t ≥ 0 {\displaystyle t\geq 0} p ( n , t ) = e − t t − n ( − n ) ! {\displaystyle p(n,t)=e^{-t}{\frac {t^{-n}}{(-n)!}}} for n ≤ 0 {\displaystyle n\leq 0} where t ≥ 0 {\displaystyle t\geq 0} . From this classification, it is apparent that we require a continuous semi-group structure, there are only three classes of scale-space kernels with a continuous scale parameter; the Gaussian kernel which forms the scale-space of continuous signals, the discrete Gaussian kernel which forms the scale-space of discrete signals and the time-causal Poisson kernel that forms a temporal scale-space over discrete time. If we on the other hand sacrifice the continuous semi-group structure, there are more options: For discrete signals, the use of generalized binomial kernels provides a formal basis for defining the smoothing operation in a pyramid. For temporal data, the one-sided truncated exponential kernels and the first-order recursive filters provide a way to define time-causal scale-spaces that allow for efficient numerical implementation and respect causality over time without access to the future. The first-order recursive filters also provide a framework for defining recursive approximations to the Gaussian kernel that in a weaker sense preserve some of the scale-space properties.
Display list
A display list, also called a command list in Direct3D 12 and a command buffer in Vulkan, is a series of graphics commands or instructions that are run when the list is executed. Systems that make use of display list functionality are called retained mode systems, while systems that do not are as opposed to immediate mode systems. In OpenGL, display lists are useful to redraw the same geometry or apply a set of state changes multiple times. This benefit is also used with Direct3D 12's bundle command lists. In Direct3D 12 and Vulkan, display lists are regularly used for per-frame recording and execution. == Origins in vector displays == The vector monitors or calligraphic displays of the 1960s and 1970s used electron beam deflection to draw line segments, points, and sometimes curves directly on a CRT screen. Because the image would immediately fade, it needed to be redrawn many times a second (storage tube CRTs retained the image until blanked, but they were unsuitable for interactive graphics). To refresh the display, a dedicated CPU called a Display Processor or Display Processing Unit (DPU) was used, which had a memory buffer for a "display list", "display file", or "display program" containing line segment coordinates and other information. Advanced Display Processors also supported control flow instructions, which were useful for drawing repetitive graphics such as text, and some could perform coordinate transformations such as 3D projection. == Home computer display list functionality == One of the earliest systems with a true display list was the Atari 8-bit computers. The display list (actually called so in Atari terminology) is a series of instructions for ANTIC, the video co-processor used in these machines. This program, stored in the computer's memory and executed by ANTIC in real-time, can specify blank lines, any of six text modes and eight graphics modes, which sections of the screen can be horizontally or vertically fine-scrolled, and trigger Display List Interrupts (called raster interrupts or HBI on other systems). The Amstrad PCW family contains a Display List function called the 'Roller RAM'. This is a 512-byte RAM area consisting of 256 16-bit pointers in RAM, one for each line of the 720 × 256 pixel display. Each pointer identifies the location of 90 bytes of monochrome pixels that hold the line's 720 pixel states. The 90 bytes of 8 pixel states are spaced at 8-byte intervals, so there are 7 unused bytes between each byte of pixel data. This suits how the text-orientated PCW constructs a typical screen buffer in RAM, where the first character's 8 rows are stored in the first 8 bytes, the second character's rows in the next 8 bytes, and so on. The Roller RAM was implemented to speed up display scrolling as it would have been unacceptably slow for its 3.4 MHz Z80 to move up the 23 KB display buffer 'by hand' i.e. in software. The Roller RAM starting entry used at the beginning of a screen refresh is controlled by a Z80-writable I/O register. Therefore, the screen can be scrolled simply by changing this I/O register. Another system using a Display List-like feature in hardware is the Amiga, which, not coincidentally, was also designed by some of the same people who developed the custom hardware for the Atari 8-bit computers. Once directed to produce a display mode, it would continue to do so automatically for every following scan line. The computer also included a dedicated co-processor, called "Copper", which ran a simple program or 'Copper List' intended for modifying hardware registers in sync with the display. The Copper List instructions could direct the Copper to wait for the display to reach a specific position on the screen, and then change the contents of hardware registers. In effect, it was a processor dedicated to servicing raster interrupts. The Copper was used by Workbench to mix multiple display modes (multiple resolutions and color palettes on the monitor at the same time), and by numerous programs to create rainbow and gradient effects on the screen. The Amiga Copper was also capable of reconfiguring the sprite engine mid-frame, with only one scanline of delay. This allowed the Amiga to draw more than its 8 hardware sprites, so long as the additional sprites did not share scanlines (or the one scanline gap) with more than 7 other sprites. i.e., so long as at least one sprite had finished drawing, another sprite could be added below it on the screen. Additionally, the later 32-bit AGA chipset allowed the drawing of bigger sprites (more pixels per row) while retaining the same multiplexing. The Amiga also had dedicated block-shifter ("blitter") hardware, which could draw larger objects into a framebuffer. This was often used in place of, or in addition to, sprites. In more primitive systems, the results of a display list can be simulated, though at the cost of CPU-intensive writes to certain display modes, color control, or other visual effect registers in the video device, rather than a series of rendering commands executed by the device. Thus, one must create the displayed image using some other rendering process, either before or while the CPU-driven display generation executes. In many cases, the image is also modified or re-rendered between frames. The image is then displayed in various ways, depending on the exact way in which the CPU-driven display code is implemented. Examples of the results possible on these older machines requiring CPU-driven video include effects such as Commodore 64/128's FLI mode, or Rainbow Processing on the ZX Spectrum. == Usage in OpenGL == To delimit a display list, the glNewList and glEndList functions are used, and to execute the list, the glCallList function is used. Almost all rendering commands that occur between the function calls are stored in the display list. Commands that affect the client state are not stored in display lists. Display lists are named with an integer value, and creating a display list with the same name as one already created overrides the first. The glNewList function expects two arguments: an integer representing the name of the list, and an enumeration for the compilation mode. The two modes include GL_COMPILE_AND_EXECUTE, which compiles and immediately executes, and GL_COMPILE, which only compiles the list. Display lists enable the use of the retained mode rendering pattern, which is a system in which graphics commands are recorded (retained) to execute in succession at a later time. This is contrary to immediate mode, where graphics commands are immediately executed on client calls. == Usage in Direct3D 12 == Command lists are created using the ID3D12Device::CreateCommandList function. Command lists may be created in several types: direct, bundle, compute, copy, video decode, video process, and video encoding. Direct command lists specify that a command list the GPU can execute, and doesn't inherit any GPU state. Bundles, are best used for storing and executing small sets of commands any number of times. This is used differently than regular command lists, where commands stored in a command list are typically executed only once. Compute command lists are used for general computations, with a common use being calculating mipmaps. A copy command list is strictly for copying and the video decode and video process command lists are for video decoding and processing respectively. Upon creation, command lists are in the recording state. Command lists may be re-used by calling the ID3D12GraphicsCommandList::Reset function. After recording commands, the command list must be transitioned out of the recording state by calling ID3D12GraphicsCommandList::Close. The command list is then executed by calling ID3D12CommandQueue::ExecuteCommandLists.
Zesta
Zesta is an online food ordering and delivery platform operating across the African region. Formerly known as Square Eats, the company rebranded to Zesta in 2025. Zesta connects customers with restaurants and stores, offering delivery services for food, groceries, parcel delivery and other essentials. == History == Zesta was originally founded as Square Eats in 2020 by twin brothers Henry Newman and Randall Newman when they were 21 years old. It was launched in Gaborone, Botswana, and quickly gained traction as a leading food delivery service in the country. The company halted operations and took a strategic decision to reinvent the business in 2022. In 2025, the company announced its rebranding to Zesta, highlighting its commitment to evolving beyond food delivery to become a super app. === COVID-19 initiative === During the COVID-19 pandemic, Zesta (then Square Eats) implemented measures to ensure safety and hygiene, including providing free gloves and hand sanitizer to drivers and introducing contactless delivery options. These efforts positioned the platform as a trusted service during the pandemic. == Service == Zesta facilitates delivery from a wide range of merchant partners via a smartphone app, available on iOS and Android platforms, or through its website. Customers can browse their favorite restaurants, place orders, and have meals delivered to their doorstep efficiently.
Key frame
In animation and filmmaking, a key frame (or keyframe) is a drawing or shot that defines the starting and ending points of a smooth transition. These are called frames because their position in time is measured in frames on a strip of film or on a digital video editing timeline. A sequence of key frames defines which movement the viewer will see, whereas the position of the key frames on the film, video, or animation defines the timing of the movement. Because only two or three key frames over the span of a second do not create the illusion of movement, the remaining frames are filled with "inbetweens". == Use of key frames as a means to change parameters == In software packages that support animation, especially 3D graphics, there are many parameters that can be changed for any one object. One example of such an object is a light. In 3D graphics, lights function similarly to real-world lights. They cause illumination, cast shadows, and create specular highlights. Lights have many parameters, including light intensity, beam size, light color, and the texture cast by the light. Supposing that an animator wants the beam size to change smoothly from one value to another within a predefined period of time, that could be achieved by using key frames. At the start of the animation, a beam size value is set. Another value is set for the end of the animation. Thus, the software program automatically interpolates the two values, creating a smooth transition. == Video editing == In non-linear digital video editing, as well as in video compositing software, a key frame is a frame used to indicate the beginning or end of a change made to a parameter. For example, a key frame could be set to indicate the point at which audio will have faded up or down to a certain level. == Video compression == In video compression, a key frame, also known as an intra-frame, is a frame in which a complete image is stored in the data stream. In video compression, only changes that occur from one frame to the next are stored in the data stream, in order to greatly reduce the amount of information that must be stored. This technique capitalizes on the fact that most video sources (such as a typical movie) have only small changes in the image from one frame to the next. Whenever a drastic change to the image occurs, such as when switching from one camera shot to another or at a scene change, a key frame must be created. The entire image for the frame must be output when the visual difference between the two frames is so great that representing the new image incrementally from the previous frame would require more data than recreating the whole image. Because video compression only stores incremental changes between frames (except for key frames), it is not possible to fast-forward or rewind to any arbitrary spot in the video stream. That is because the data for a given frame only represents how that frame was different from the preceding one. For that reason, it is beneficial to include key frames at arbitrary intervals while encoding video. For example, a key frame may be output once for each 10 seconds of video, even though the video image does not change enough visually to warrant the automatic creation of the key frame. That would allow seeking within the video stream at a minimum of 10-second intervals. The downside is that the resulting video stream will be larger in disk size because many key frames are added when they are not necessary for the frame's visual representation. This drawback, however, does not produce significant compression loss when the bitrate is already set at a high value for better quality (as in the DVD MPEG-2 format).
Odor source localization
Odor source localization (OSL) is the problem of locating the origin of an airborne or waterborne chemical plume using one or more mobile sensors, typically robots equipped with chemical sensors. The task sits at the intersection of robotics, fluid dynamics and machine olfaction. Chemical plumes in turbulent flows are intermittent and patchy, and most chemical sensors respond slowly and have limited selectivity, so the instantaneous reading available to a moving sensor is a poor proxy for the underlying time-averaged concentration field. Robotic OSL has been studied since the late 1980s and has applications including the detection of gas leaks, search and rescue after industrial accidents, and environmental monitoring of industrial emissions. == History == Robotic odor search emerged in the late 1980s and 1990s, drawing on earlier work in chemical ecology that had described how moths and other insects locate distant pheromone sources. R. A. Russell at Monash University was among the first to build mobile robots that followed chemical trails on the floor and tracked airborne odor plumes. Distributed and multi-robot odor search were investigated by Hayes, Martinoli and Goodman at the California Institute of Technology and EPFL, who studied cooperative plume-tracing on simulated and physical robot swarms. In 2007 Vergassola, Villermaux and Shraiman introduced infotaxis, an information-theoretic search strategy in which a sensor moves so as to maximize the expected information gain about source location, rather than following a chemical concentration gradient; the paper appeared in Nature and prompted substantial follow-up work in the robotics community. From the mid-2010s, multi-rotor unmanned aerial vehicles carrying lightweight chemical sensors became a common experimental platform for OSL research. == Problem formulation == OSL is generally decomposed into three sub-problems: plume detection (deciding whether a chemical signal is present), plume traversal (moving so as to remain in contact with the plume), and source declaration (deciding when the source has been reached). The mathematical difficulty depends strongly on the assumed dispersion model. In laminar or low-Reynolds number flows a Gaussian advection–diffusion model gives a smooth concentration field with a well-defined gradient. In turbulent flows, which dominate most realistic environments, the plume is filamentary: the sensor receives short, randomly spaced bursts of chemical separated by periods of zero signal, and the time-averaged field is not a useful guide on the time scales at which a robot must act. Source-term estimation, surveyed by Hutchinson and colleagues, additionally aims to recover both the position and the release rate of the source from the observed concentrations, often using probabilistic filters. == Biological inspiration == Many OSL strategies are explicitly modeled on the behavior of male moths flying upwind toward a pheromone source. As reviewed by Cardé and Willis, moths combine an upwind surge whenever they detect a filament of pheromone with a wider crosswind cast when contact is lost, producing a characteristic zig-zag trajectory that has been transposed onto mobile robots by several groups. Other biological models draw on the search behavior of dogs and of marine animals such as blue crabs and lobsters, which integrate chemical and bilateral hydrodynamic cues over much shorter ranges. == Algorithms and strategies == === Reactive strategies === Reactive strategies select the next motion as a direct function of the current sensor reading. Chemotaxis steers along the locally estimated concentration gradient, which is effective in laminar plumes but degrades severely in turbulence. Anemotaxis exploits a measured wind direction by surging upwind when chemical contact is made. The bio-inspired cast-and-surge family combines anemotaxis with a deterministic crosswind cast on contact loss, and is the dominant reactive approach for turbulent environments. === Probabilistic and information-theoretic strategies === Probabilistic methods maintain a posterior distribution over possible source locations and choose actions that improve that distribution. The infotaxis strategy of Vergassola, Villermaux and Shraiman selects the move that maximizes the expected reduction in entropy of the source-location posterior, and is effective in regimes where the spatial gradient is unusable. Bayesian source-term estimation extends this idea by inferring both source position and release rate, typically using particle filters or sequential Monte Carlo. === Map-based strategies === Map-based methods build a spatial model of the time-averaged gas distribution from sensor readings collected along the robot's trajectory and search for local maxima in that model. Lilienthal and colleagues describe a family of kernel-based gas distribution mapping techniques in which point measurements are convolved with a Gaussian kernel to produce a spatially extrapolated estimate. Such methods are most useful when the source can be assumed quasi-stationary and the robot is able to revisit locations. === Multi-robot and swarm strategies === Multiple robots searching cooperatively can shorten search times. Cooperative formations spread the sensors across the crosswind axis, making detection of an intermittent plume more likely. Swarm-based approaches, reviewed by Wang and colleagues, deploy larger numbers of simpler agents and rely on collective behavior rather than centralized planning; reported advantages include improved coverage of the search area and the possibility of locating multiple sources in parallel. == Sensors and platforms == Most OSL systems use metal-oxide semiconductor (MOX) sensors, photoionization detectors or electrochemical cells, which trade off sensitivity, selectivity, response time and power consumption. Ishida and colleagues describe how these sensors interact with airflow around the robot body, an effect that motivates careful aerodynamic design and active sampling. Mobile platforms include wheeled ground robots for indoor and structured outdoor environments, multi-rotor unmanned aerial vehicles for open spaces and elevated sources, and autonomous underwater vehicles for chemical plumes in the marine environment. == Notable systems == Among the early demonstrations, R. A. Russell's series of differential-drive robots at Monash University localized volatile sources in still and ventilated rooms during the 1990s. The Smelling Nano Aerial Vehicle reported by Burgués and colleagues used a Crazyflie nano-quadcopter (approximately 27 grams in mass and 10 cm across) carrying a custom MOX gas sensing board, and built three-dimensional gas distribution maps of indoor releases from sweeping flights of less than three minutes. The GADEN simulator, released by Monroy and colleagues, couples three-dimensional dispersion computed from an OpenFOAM CFD solver with models of MOX and photo-ionization gas sensors, and is widely used to test mobile-robot olfaction algorithms in simulation. == Applications == Reported applications include the localization of natural-gas and methane leaks in urban infrastructure, search for chemical contamination after industrial accidents, search and rescue, and environmental monitoring of industrial emissions. Drug- and explosives-detection robots are an adjacent application area, although these typically rely on close-range sniffing rather than long-range plume tracking. == Open challenges == Open challenges identified in recent reviews include the limited speed, selectivity and stability of available chemical sensors; the scarcity of standardized, large-scale benchmarks comparable to those available in computer vision; reliable handling of multi-source environments, where standard single-source assumptions fail; and the integration of OSL with other autonomous-vehicle subsystems such as obstacle avoidance and navigation in three-dimensional turbulent flow.
Zardoz (computer security)
In computer security, the Security-Digest list, better known as the Zardoz list, was a semi-private full disclosure mailing list run by Neil Gorsuch from 1989 through 1991. It identified weaknesses in systems and gave directions on where to find them. It was a perennial target for computer hackers, who sought archives of the list for information on undisclosed software vulnerabilities. == Membership restrictions == Access to Zardoz was approved on a case-by-case basis by Gorsuch, principally by reference to the user account used to send subscription requests; requests were approved for root users, valid UUCP owners, or system administrators listed at the NIC. The openness of the list to users other than Unix system administrators was a regular topic of conversation, with participants expressing concern that vulnerabilities and exploitation details disclosed on the list were liable to spread to hackers. The circulation of Zardoz postings was an open secret among computer hackers, and mocked in a Phrack parody of an IRC channel populated by security experts. == Notable participants == Keith Bostic discussed BSD Sendmail vulnerabilities Chip Salzenberg discussed Peter Honeyman's posting of a UUCP worm, and shell script security Gene Spafford discussed VMS and Ultrix bugs, and relayed law enforcement enquiries about the Morris Worm Tom Christiansen discussed SUID shell scripts Chris Torek discussed devising exploits from general descriptions of vulnerabilities Henry Spencer discussed Unix security Brendan Kehoe discussed systems security Alec Muffett announced Crack, the Unix password cracker The majority of Zardoz participants were Unix systems administrators and C software developers. Neil Gorsuch and Gene Spafford were the most prolific contributors to the list.