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.
Nolot
Nolot is a chess test suite with 11 positions from real games. They were compiled by Pierre Nolot (French: [nɔ.lo]) for the French chess magazine Gambisco and posted on the rec.games.chess Usenet group in 1994. They were designed to be particularly hard to solve for chess engines to solve at the time, although modern engines can find a solution near-instantaneously. == Problem 1 == FEN: r3qb1k/1b4p1/p2pr2p/3n4/Pnp1N1N1/6RP/1B3PP1/1B1QR1K1 w - - 0 1 26.Nxh6!! c3 (26... Rxh6 27.Nxd6 Qh5 (best) 28.Rg5! Qxd1 29.Nf7+ Kg8 30.Nxh6+ Kh8 31.Rxd1 c3 32.Nf7+ Kg8 33.Bg6! Nf4 34.Bxc3 Nxg6 35.Bxb4 Kxf7 36.Rd7+ Kf6 37.Rxg6+ Kxg6 38.Rxb7 ±) 27.Nf5! cxb2 28.Qg4 Bc8 (28... g6!? 29.Kh2! 29.Qd7 30.Nh4 Bc6 31.Nc5! dxc 32.Rxe6 Nf6 33.Nxg6+ Kg7 34.Qg5 Nbd5 35.Ne5 Kh8 36.Nxd7 ±) 29.Qh4+ Rh6 30.Nxh6 gxh6 31.Kh2! Qe5 32.Ng5 Qf6 33.Re8 Bf5 34.Qxh6 (missing a mate in 6: 34.Nf7+ Qxf7 35.Qxh6+ Bh7 36.Rxa8 Nf6 37.Rxf8 Qxf8 38.Qxf8+ Ng8 39.Qg7#) 34...Qxh6 35.Nf7+ Kh7 36.Bxf5+ Qg6 37.Bxg6+ Kg7 38.Rxa8 Be7 39.Rb8 a5 40.Be4+ Kxf7 41.Bxd5+ 1–0 The best Novag computer, the Diablo 68000, finds 26. Nxh6 after seven and a half months (Pierre Nolot has let it run on the position for 14 months and one day, until a power failure stopped an analysis of over 80,000,000,000 nodes.) but for wrong reasons: it evaluates white's position as inferior and thinks this move would enable it to draw. Today Gambit Tiger 2.0 for example can find it quite quickly: Most free engines running on 64-bit processors in 2010 could solve this problem and the others in a few seconds. 1.Qd4 c3 2.Bxc3 Nxc3 3.Qxb4 Nxe4 4.Qxb7 Rb8 5.Qxb8 Qxb8 6.Bxe4 d5 7.Rb1 μ (-1.20) Depth: 12 00:00:09 6055 kN 1.Nxh6 c3 2.Nf5 cxb2 3.Qg4 Rb8 4.Nxg7 Rg6 5.Qxg6 Qxg6 6.Rxg6 Bxg7 7.Nxd6 ³ (-0.48) Depth: 12 00:00:21 14368 kN 1.Nxh6 c3 2.Nf5 cxb2 3.Qg4 Rc8 4.Nxg7 Rg6 5.Nxe8 Rxg4 6.Rxg4 Rxe8 7.Rg6 μ (-0.74) Depth: 13 00:00:55 38455 kN 1.Ne3 Rxe4 2.Bxe4 Qxe4 3.Nxd5 Qxd5 4.Qc1 Qf5 5.Qxh6+ Qh7 6.Qe6 Nd3 7.Re2 Nxb2 8.Rxb2 ³ (-0.58) Depth: 13 00:01:30 62979 kN 1.Ne3 Rxe4 ³ (-0.58) Depth: 14 00:02:02 84941 kN 1.Ne3 Nxe3 2.Rexe3 Bxe4 3.Qg4 Rg6 4.Qxe4 Qxe4 5.Bxe4 Rxg3 6.Rxg3 d5 7.Bf5 Re8 8.Bc3 ³ (-0.30) Depth: 15 00:03:05 128968 kN 1.Nxh6 ² (0.32) Depth: 15 00:07:58 350813 kN With the next ply showing a clear advantage. Stockfish 14dev 64bit 4CPU running on 2020 hardware recognises the significance of Nxh6!! in 1 second. Stockfish_21092606_x64_avx2: NNUE evaluation using nn-13406b1dcbe0.nnue enabled. 19/32 00:01 7708k 4882k +3,00 Nxh6 Rxh6 Nxd6 Qh5 Bg6 Qxd1 Nf7+ Kg8 Nxh6+ gxh6 Bh5+ Kh7 Rxd1 c3 Bxc3 Nxc3 Rd7+ Kh8 Rxb7 Ne4 Re3 Nxf2 Kxf2 Bc5 Ke2 Bxe3 Kxe3 Nd5+ Kf2 49/73 15:02 5118270k 5673k +6,15 Nxh6 Rxh6 Nxd6 Qh5 Rg5 Qxd1 Nf7+ Kg8 Nxh6+ Kh8 Rxd1 c3 Nf7+ Kg8 Bg6 Nf4 Bxc3 Nbd5 Rb1 Bc6 Bd2 Nxg6 Rxg6 Ne7 Rxc6 Nxc6 Rb6 Rc8 Ng5 a5 Ra6 Bb4 Be3 Ne5 Bd4 Nc6 Bb6 Bd2 h4 Kf8 Bc5+ Kg8 Be3 Bxe3 fxe3 Kf8 Kf2 Ke7 Nf3 Kd7 Rb6 Ne7 Rb5 Kd6 Rxa5 Rc2+ Kg3 Re2 Nd4 Rxe3+ Kf4 Rd3 Nf5+ Kc7 Nxe7 == Problem 2 == FEN: r4rk1/pp1n1p1p/1nqP2p1/2b1P1B1/4NQ2/1B3P2/PP2K2P/2R5 w - - 0 1 22.Rxc5!! Nxc5 23.Nf6+ Kh8 24.Qh4 Qb5+ (computers think there is perpetual check here, but...) 25.Ke3! 25... h5 26.Nxh5 Qxb3+ (26... d5+ 27.Bxd5 Qd3 28.Kf2 Ne4+ 29.Bxe4 Qd4+ 30.Kg2 Qxb2+ 31.Kh3 ±) and White won in 41 moves. Today Deep Junior 8.ZX for example finds it very quickly (around 1 minute): 1.Kd1 Rac8 2.Bh6 Qb5 3.Rc3 Qf1+ 4.Kc2 Rc6 5.Bxf8 −+ (-2.11) Depth: 12 00:00:04 10422 kN 1.Nxc5 Nxc5 2.Rxc5 Qxc5 3.e6 Rae8 4.e7 Nc8 5.Kf1 Nxd6 6.Bf6 b5 −+ (-2.10) Depth: 12 00:00:14 25054 kN 1.Bf6! μ (-1.35) Depth: 12 00:00:17 34601 kN 1.Bf6 Qb5+ 2.Ke1 Bb4+ 3.Kf2 Bc5+ = (0.00) Depth: 12 00:00:20 34601 kN 1.Bf6 Qb5+ 2.Ke1 Nxf6 3.Nxf6+ Kg7 4.Nh5+ gxh5 5.Qf6+ Kg8 6.Qg5+ Kh8 7.Qf6+ = (0.00) Depth: 15 00:01:01 130544 kN 1.Rxc5! = (0.15) Depth: 15 00:01:12 145875 kN 1.Rxc5 Nxc5 2.Nf6+ Kh8 3.Qh4 Qb5+ 4.Ke3 h5 5.Nxh5 Qd3+ 6.Kf2 Ne4+ 7.fxe4 Qd4+ 8.Kf1 Qd3+ 9.Ke1 Qb1+ 10.Bd1 ± (2.18) Depth: 15 00:01:18 145875 kN Stockfish 14dev 64bit 4CPU running on 2020 hardware recognises the significance of Rxc5!! in 1 second. Stockfish_21092606_x64_avx2: NNUE evaluation using nn-13406b1dcbe0.nnue enabled. 21/25 00:01 5822k 5545k +6,61 Rxc5 Qxc5 Nxc5 Nxc5 Bh6 Nbd7 Bxf8 Rxf8 Qe3 Rc8 f4 Nxe5 Qxe5 Ne6 Bxe6 Rc2+ Kd3 Rxh2 46/86 11:27 5057055k 7355k +7,61 Rxc5 Qxc5 Nxc5 Nxc5 Bf6 Ne6 Qh6 Nd4+ Kf2 Nf5 Qg5 Nd7 h4 Nxf6 Qxf6 Ng7 d7 b5 Bd5 Rab8 b4 Nh5 Bxf7+ Rxf7 d8R+ Rxd8 Qxd8+ Rf8 Qd5+ Kg7 e6 Kf6 Qd7 Ng7 Qd4+ Kxe6 Qxg7 Rf7 Qc3 Ke7 Qc5+ Ke8 Qc8+ Ke7 h5 gxh5 Kg3 h4+ Kh2 h6 Qc5+ Kf6 Qxb5 Kg7 f4 Rxf4 Qe5+ Rf6 b5 h3 Qd4 Kg8 Qxf6 h5 Blacks 22. .. Nxc5 is suboptimal and leads faster mate 77/44 09:18 6987714k 12518k +M22 Nf6+ Kh8 Qh4 Qb5+ Ke3 Qxb3+ axb3 h5 Nxh5 Nd5+ Kd4 Ne6+ Kxd5 Nxg5 Qxg5 gxh5 f4 Rad8 f5 f6 Qxh5+ Kg7 Qg6+ Kh8 e6 b6 e7 Rb8 exf8Q+ Rxf8 Ke6 b5 Ke7 Rb8 Qh5+ Kg7 Qf7+ Kh8 Kxf6 Rf8 Qxf8+ Kh7 Qg7+ == Problem 3 == FEN: r2qk2r/ppp1b1pp/2n1p3/3pP1n1/3P2b1/2PB1NN1/PP4PP/R1BQK2R w KQkq - 0 1 12.Nxg5!! Bxd1 13.Nxe6 Qb8 14.Nxg7+!! Kf8 15.Bh6! Bg4 16.0-0+ Kg8 17.Rf4 ± White wins with a queen sac but black has defensive resources. Stockfish 8 64bit 3CPU running on 2016 hardware recognizes the significance of Nxg5!! in 55 seconds. Stockfish 14 dev (Stockfish_21092606_x64_avx2) 64bit 4CPU running on 2020 hardware recognizes the significance of Nxg5!! in 1 second. NNUE evaluation using nn-13406b1dcbe0.nnue enabled. 21/34 00:01 8291k 4530k +2,78 Nxg5 Bxd1 Nxe6 Qb8 Nxg7+ Kd8 Kxd1 b5 N3f5 Bf8 Rf1 Kc8 Nh5 Kb7 Bxb5 Ne7 g4 a6 Ba4 Nxf5 gxf5 Ka7 Nf4 c5 47/59 37:49 10390430k 4578k +3,16 Nxg5 Bxd1 Nxe6 Qb8 Nxg7+ Kd8 Kxd1 b5 Rf1 Kc8 N3f5 Bf8 Ne6 Kd7 Nf4 Ne7 g4 a5 Ke2 Qb7 h4 Ra6 a3 Kc8 Be3 Kb8 Kf3 Rb6 Bd2 Qc8 Kg3 c5 Be3 c4 Nxe7 Bxe7 Bf5 Qd8 h5 Qg8 Kh3 Bg5 Rf3 Ra6 Raf1 b4 Nxd5 Qxd5 Bxg5 bxc3 bxc3 Rb6 Be3 Rb3 Blacks 14 .. Kf8 is suboptimal and leads loss fast 41/68 06:31 3269727k 8350k +9,28 Bh6 Kg8 Rxd1 Bf8 N3h5 Bxg7 Nxg7 Qf8 Nf5 Ne7 Bxf8 Nxf5 Bxf5 Rxf8 Be6+ Kg7 Rd3 Rf4 Bxd5 c6 Rg3+ Kf8 Rf3 Rxf3 Bxf3 Kg7 Rf1 Re8 Be4 Re6 Ke2 a5 Ke3 Rh6 h3 a4 Kf4 Re6 h4 Re8 Ke3 h6 h5 Rf8 Rxf8 Kxf8 == Problem 4 == FEN: r1b1kb1r/1p1n1ppp/p2ppn2/6BB/2qNP3/2N5/PPP2PPP/R2Q1RK1 w kq - 0 1 10.Nxe6!! Qxe6 11.Nd5 Kd8 12.Bg4 Qe5 13.f4 Qxe4 (13...Qxb2 stronger but not sufficient: 14.Bxd7 Bxd7 15.Rb1 Qa3 16.Nxf6 Bb5 17.Qd4 Qc5 18.Rfd1 ±) 14.Bxd7 Bxd7 15.Nxf6 gxf6 16.Bxf6+ Kc7 17.Bxh8 and Black resigned on move 27. Stockfish 14dev 64bit 4CPU running on 2020 hardware recognises the significance of 10.Nxe6 in 1 second. Stockfish_21092606_x64_avx2: NNUE evaluation using nn-13406b1dcbe0.nnue enabled. 22/37 00:01 6955k 5367k +4,00 Nxe6 Qxe6 Nd5 Kd8 Bg4 Qe5 f4 Qxb2 Rb1 Qa3 Bxd7 Bxd7 Nxf6 Bb5 Rf3 Qxa2 c4 Bxc4 Rf2 Qa5 Nd5+ f6 Nxf6 Kc7 Rc1 b5 Qd5 gxf6 Bxf6 Kb8 Rxc4 Qe1+ Rf1 51/70 47:10 14538911k 5137k +5,76 Nxe6 Qxe6 Nd5 Kd8 Bg4 Qe5 f4 Qxe4 Bxd7 Bxd7 Nxf6 Qf5 Qd4 Kc8 Nd5 Bc6 c4 f6 Nb6+ Kb8 Bh4 Be7 Rae1 Bd8 Nxa8 Kxa8 Bf2 Kb8 Qxd6+ Bc7 Ba7+ Kc8 Qe6+ Qxe6 Rxe6 h5 h4 Rd8 Re7 g6 Be3 Ba5 Kf2 Rd6 Rc1 Bd8 Rg7 Be4 Rg8 Kd7 c5 Rd3 Rc4 Bd5 Rg7+ Ke6 Rd4 Rxd4 Bxd4 Kf5 Rd7 Bc6 Rxd8 Kxf4 Bxf6 == Problem 5 == FEN: r2qrb1k/1p1b2p1/p2ppn1p/8/3NP3/1BN5/PPP3QP/1K3RR1 w - - 0 1 21.e5!! dxe5 22.Ne4! Nh5 23.Qg6!? (stronger is 23.Qg4!! Nf4 24.Nf3 Qc7 25.Nh4 ± ) 23...exd4? (23...Nf4 24.Rxf4! exf4 25.Nf3! Qb6 26.Rg5!! covering b5 and threatening Nf6 or Ne5-f7+) 24.Ng5 1−0 Stockfish 8 64bit 3CPU running on 2016 hardware recognises the significance of 21.e5 in 5 seconds. Stockfish 12 dev (Stockfish_20062212_x64_modern) 64bit 1CPU running on 2016 hardware recognizes the significance of 21.e5 in 11 seconds. 25/42 00:06 7 963k 1309k +6,93 e5 Nh5 Ne4 dxe5 Nf3 Nf4 Qg4 Qc7 Nh4 Bc6 Nf6 g5 Rxf4 exf4 Qh5 Qe7 Ng6+ Kg7 Nxe7 Rxe7 Ng4 37/62 03:12 298 083k 1545k +10,70 e5 Ng4 Qxg4 Qg5 Qh3 Qxe5 Nde2 g5 Rxf8+ Kg7 Rff1 Rf8 Re1 Qf5 Qg3 Rad8 Nd4 Qf4 Nxe6+ Bxe6 Rxe6 Qxg3 == Problem 6 == FEN: rnbqk2r/1p3ppp/p7/1NpPp3/QPP1P1n1/P4N2/4KbPP/R1B2B1R b kq - 0 1 13... axb5!! offers an exchange to keep the white queen out of play. 14.Qxa8 Bd4 15.Nxd4 cxd4 16.Qxb8 0-0! 17.Ke1 Qh4 18.g3 Qf6 19.Bf4 g5? (Ivanchuk found 19...d3! during post-game analysis.) 20.Rc1 exf4 21.Qxf4 Qd4 22.Rd1 bxc4 23.e5 Qc3+ 24.Rd2 Re8 25.Bxd3 cxd3 −+ Tasc R30 finds 19... d3! in 2 1/2 hours. 19... Bf5!! is even stronger than 19... d3. Position is already lost at 19... d3 +8.00 for black, ... Bf5 not much better Stockfish 14dev 64bit 4CPU running on 2020 hardware recognises the significance of axb5!! in 1 second. Stockfish_21092606_x64_avx2: NNUE evaluation using nn-13406b1dcbe0.nnue enabled. 21/28 00:01 9264k 4714k -1,22 axb5 Qxa8 Bd4 Nxd4 cxd4 h3 Nf6 Bg5 0-0 cxb5 h6 Bxf6 Qxf6 Re1 Nd7 Kd1 Qg6 Qa4 Qg3 Qc2 Qxa3 Bd3 Qxb4 Qb1 46/67 1:05:00 18113493k 4644k -2,40 axb5 Qxa8 Bd4 h3 Nf6 Nxd4 exd4 Kf2 Nxe4+ Kg1 Nd7 Bg5 Qxg5 Qxc8+ Ke7 Qc7 Qe5 d6+ Qxd6 Qxd6+ Kxd6 bxc5+ Ndxc5 cxb5 d3 h4 d2 Rh3 Ke5 Be2 f5 Ra2 Rd8 Bd1 Rd4 Re3 f4 Re2 b6 a4 Kd6 Rc2 Kd5 Ra2 h6 Rb2 Nxa4 Bxa4 Rxa4 Rexd2+ Nxd2 Rxd2+ Kc4 Rd7 g6 == Problem 7 == FEN 1r1bk2r/2R2ppp/p3p3/1b2P2q/4QP2/4N3/1B4PP/3R2K1 w k - 0 1 1.Rxd8+!! Rxd8 (1...Kxd8 2.Ra7! Qe2 3.Qd4+ Ke8 4.h3 Qe1+ 5.Kh2 Rd8 6.Qc5 Qh4 7.Ba3 Rd7 8.Ra8+ Rd8 9.g3 1−0)
Skyline operator
The skyline operator is the subject of an optimization problem and computes the Pareto optimum on tuples with multiple dimensions. This operator is an extension to SQL proposed by Börzsönyi et al. to filter results from a database to keep only those objects that are not dominated by any other point on all dimensions. The name skyline comes from the view on Manhattan from the Hudson River, where those buildings can be seen that are not hidden by any other. A building is visible if it is not dominated by a building that is taller or closer to the river (two dimensions, distance to the river minimized, height maximized). Another application of the skyline operator involves selecting a hotel for a holiday. The user wants the hotel to be both cheap and close to the beach. However, hotels that are close to the beach may also be expensive. In this case, the skyline operator would only present those hotels that are not worse than any other hotel in both price and distance to the beach. == Formal specification == The skyline operator returns tuples that are not dominated by any other tuple. A tuple dominates another if it is at least as good in all dimensions and better in at least one dimension. Formally, we can think of each tuple as a vector p , q ∈ R n {\displaystyle p,q\in \mathbb {R} ^{n}} . p {\displaystyle p} dominates q {\displaystyle q} (written: p ≻ q {\displaystyle p\succ q} ) if p {\displaystyle p} is at least as good as q {\displaystyle q} in every dimension, and superior in at least one: p ≻ q ⇔ ∀ i ∈ [ n ] . p [ i ] ⪰ q [ i ] ∧ ∃ j ∈ [ n ] . p [ j ] ≻ q [ j ] . {\displaystyle p\succ q\Leftrightarrow \forall i\in [n].p[i]\succeq q[i]\wedge \exists j\in [n].p[j]\succ q[j].} Dominance ( p ≻ q {\displaystyle p\succ q} ) can be defined as any strict partial ordering, for example greater (with ≻:=> {\displaystyle \succ :=>} and ⪰:=≥ {\displaystyle \succeq :=\geq } ) or less (with ≻:=< {\displaystyle \succ :=<} and ⪰:=≤ {\displaystyle \succeq :=\leq } ). Assuming two dimensions and defining dominance in both dimensions as greater, we can compute the skyline in SQL-92 as follows: == Proposed syntax == As an extension to SQL, Börzsönyi et al. proposed the following syntax for the skyline operator: where d1, ... dm denote the dimensions of the skyline and MIN, MAX and DIFF specify whether the value in that dimension should be minimised, maximised or simply be different. Without an SQL extension, the SQL query requires an antijoin with not exists: == Implementation == The skyline operator can be implemented directly in SQL using current SQL constructs, but this has been shown to be very slow in disk-based database systems. Other algorithms have been proposed that make use of divide and conquer, indices, MapReduce and general-purpose computing on graphics cards. Skyline queries on data streams (i.e. continuous skyline queries) have been studied in the context of parallel query processing on multicores, owing to their wide diffusion in real-time decision making problems and data streaming analytics. Exasol features a native implementation.
VMDS
VMDS abbreviates the relational database technology called Version Managed Data Store provided by GE Energy as part of its Smallworld technology platform and was designed from the outset to store and analyse the highly complex spatial and topological networks typically used by enterprise utilities such as power distribution and telecommunications. VMDS was originally introduced in 1990 as has been improved and updated over the years. Its current version is 6.0. VMDS has been designed as a spatial database. This gives VMDS a number of distinctive characteristics when compared to conventional attribute only relational databases. == Distributed server processing == VMDS is composed of two parts: a simple, highly scalable data block server called SWMFS (Smallworld Master File Server) and an intelligent client API written in C and Magik. Spatial and attribute data are stored in data blocks that reside in special files called data store files on the server. When the client application requests data it has sufficient intelligence to work out the optimum set of data blocks that are required. This request is then made to SWMFS which returns the data to the client via the network for processing. This approach is particularly efficient and scalable when dealing with spatial and topological data which tends to flow in larger volumes and require more processing then plain attribute data (for example during a map redraw operation). This approach makes VMDS well suited to enterprise deployment that might involve hundreds or even thousands of concurrent clients. == Support for long transactions == Relational databases support short transactions in which changes to data are relatively small and are brief in terms in duration (the maximum period between the start and the end of a transaction is typically a few seconds or less). VMDS supports long transactions in which the volume of data involved in the transaction can be substantial and the duration of the transaction can be significant (days, weeks or even months). These types of transaction are common in advanced network applications used by, for example, power distribution utilities. Due to the time span of a long transaction in this context the amount of change can be significant (not only within the scope of the transaction, but also within the context of the database as a whole). Accordingly, it is likely that the same record might be changed more than once. To cope with this scenario VMDS has inbuilt support for automatically managing such conflicts and allows applications to review changes and accept only those edits that are correct. == Spatial and topological capabilities == As well as conventional relational database features such as attribute querying, join fields, triggers and calculated fields, VMDS has numerous spatial and topological capabilities. This allows spatial data such as points, texts, polylines, polygons and raster data to be stored and analysed. Spatial functions include: find all features within a polygon, calculate the Voronoi polygons of a set of sites and perform a cluster analysis on a set of points. Vector spatial data such as points, polylines and polygons can be given topological attributes that allow complex networks to be modelled. Network analysis engines are provided to answer questions such as find the shortest path between two nodes or how to optimize a delivery route (the travelling salesman problem). A topology engine can be configured with a set of rules that define how topological entities interact with each other when new data is added or existing data edited. == Data abstraction == In VMDS all data is presented to the application as objects. This is different from many relational databases that present the data as rows from a table or query result using say JDBC. VMDS provides a data modelling tool and underlying infrastructure as part of the Smallworld technology platform that allows administrators to associate a table in the database with a Magik exemplar (or class). Magik get and set methods for the Magik exemplar can be automatically generated that expose a table's field (or column). Each VMDS row manifests itself to the application as an instance of a Magik object and is known as an RWO (or real world object). Tables are known as collections in Smallworld parlance. # all_rwos hold all the rwos in the database and is heterogeneous all_rwos << my_application.rwo_set() # valve_collection holds the valve collection valves << all_rwos.select(:collection, {:valve}) number_of_valves << valves.size Queries are built up using predicate objects: # find 'open' valves. open_valves << valves.select(predicate.eq(:operating_status, "open")) number_of_open_valves << open_valves.size _for valve _over open_valves.elements() _loop write(valve.id) _endloop Joins are implemented as methods on the parent RWO. For example, a manager might have several employees who report to him: # get the employee collection. employees << my_application.database.collection(:gis, :employees) # find a manager called 'Steve' and get the first matching element steve << employees.select(predicate.eq(:name, "Steve").and(predicate.eq(:role, "manager")).an_element() # display the names of his direct reports. name is a field (or column) # on the employee collection (or table) _for employee _over steve.direct_reports.elements() _loop write(employee.name) _endloop Performing a transaction: # each key in the hash table corresponds to the name of the field (or column) in # the collection (or table) valve_data << hash_table.new_with( :asset_id, 57648576, :material, "Iron") # get the valve collection directly valve_collection << my_application.database.collection(:gis, :valve) # create an insert transaction to insert a new valve record into the collection a # comment can be provide that describes the transaction transaction << record_transaction.new_insert(valve_collection, valve_data, "Inserted a new valve") transaction.run()
QuickPar
QuickPar is a computer program that creates parchives used as verification and recovery information for a file or group of files, and uses the recovery information, if available, to attempt to reconstruct the originals from the damaged files and the PAR volumes. Designed for the Microsoft Windows operating system, in the past it was often used to recover damaged or missing files that have been downloaded through Usenet. QuickPar may also be used under Linux via Wine. There are two main versions of PAR files: PAR and PAR2. The PAR2 file format lifts many of its previous restrictions. QuickPar is freeware but not open-source. It uses the Reed-Solomon error correction algorithm internally to create the error correcting information. == Replacement == Since QuickPar hasn't been updated in 21 years, it is considered abandonware. Currently, MultiPar is accepted as the software that replaces QuickPar. MultiPar is actively being developed by Yutaka Sawada. == 64-bit versions == At present the command line version of QuickPar for Linux command line is available as a 64-bit version. None of the GUI versions available presently offer a 64-bit version.
Cloud computing
Cloud computing is defined by the International Organization for Standardization (ISO) as "a paradigm for enabling network access to a scalable and elastic pool of shareable physical or virtual resources with self-service provisioning and administration on demand". It is commonly referred to as "the cloud". == Characteristics == In 2011, the National Institute of Standards and Technology (NIST) identified five "essential characteristics" for cloud systems. Below are the exact definitions according to NIST: On-demand self-service: "A consumer can unilaterally provision computing capabilities, such as server time and network storage, as needed automatically without requiring human interaction with each service provider." Broad network access: "Capabilities are available over the network and accessed through standard mechanisms that promote use by heterogeneous thin or thick client platforms (e.g., mobile phones, tablets, laptops, and workstations)." Resource pooling: " The provider's computing resources are pooled to serve multiple consumers using a multi-tenant model, with different physical and virtual resources dynamically assigned and reassigned according to consumer demand." Rapid elasticity: "Capabilities can be elastically provisioned and released, in some cases automatically, to scale rapidly outward and inward commensurate with demand. To the consumer, the capabilities available for provisioning often appear unlimited and can be appropriated in any quantity at any time." Measured service: "Cloud systems automatically control and optimize resource use by leveraging a metering capability at some level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported, providing transparency for both the provider and consumer of the utilized service. By 2023, the International Organization for Standardization (ISO) had expanded and refined the list. == History == The history of cloud computing extends to the 1960s, with the initial concepts of time-sharing becoming popularized via remote job entry (RJE). The "data center" model, where users submitted jobs to operators to run on mainframes, was predominantly used during this era. This period saw broad experimentation with making large-scale computing power more accessible through time-sharing, while optimizing infrastructure, platforms, and applications to improve efficiency for end users. The "cloud" metaphor for virtualized services dates to 1994, when it was used by General Magic for the universe of "places" that mobile agents in the Telescript environment could "go". The metaphor is credited to David Hoffman, a General Magic communications specialist, based on its long-standing use in networking and telecom. The expression cloud computing became more widely known in 1996 when Compaq Computer Corporation drew up a business plan for future computing and the Internet. The company's ambition was to supercharge sales with "cloud computing-enabled applications". The business plan foresaw that online consumer file storage would likely be commercially successful. As a result, Compaq decided to sell server hardware to internet service providers. In the 2000s, the application of cloud computing began to take shape with the establishment of Amazon Web Services (AWS) in 2002, which allowed developers to build applications independently. In 2006 Amazon Simple Storage Service, known as Amazon S3, and the Amazon Elastic Compute Cloud (EC2) were released. In 2008 NASA's development of the first open-source software for deploying private and hybrid clouds. The following decade saw the launch of various cloud services. In 2010, Microsoft launched Microsoft Azure, and Rackspace Hosting and NASA initiated an open-source cloud-software project, OpenStack. IBM introduced the IBM SmartCloud framework in 2011, and Oracle announced the Oracle Cloud in 2012. In December 2019, Amazon launched AWS Outposts, a service that extends AWS infrastructure, services, APIs, and tools to customer data centers, co-location spaces, or on-premises facilities. == Value proposition == Cloud computing can shorten time to market by offering pre-configured tools, scalable resources, and managed services, allowing users to focus on core business value rather than maintaining infrastructure. Cloud platforms can enable organizations and individuals to reduce upfront capital expenditures on physical infrastructure by shifting to an operational expenditure model, where costs scale with usage. Cloud platforms also offer managed services and tools, such as artificial intelligence, data analytics, and machine learning, which might otherwise require significant in-house expertise and infrastructure investment. While cloud computing can offer cost advantages through effective resource optimization, organizations often face challenges such as unused resources, inefficient configurations, and hidden costs without proper oversight and governance. Many cloud platforms provide cost management tools, such as AWS Cost Explorer and Azure Cost Management, and frameworks like FinOps have emerged to standardize financial operations in the cloud. Cloud computing also facilitates collaboration, remote work, and global service delivery by enabling secure access to data and applications from any location with an internet connection. Cloud providers offer various redundancy options for core services, such as managed storage and managed databases, though redundancy configurations often vary by service tier. Advanced redundancy strategies, such as cross-region replication or failover systems, typically require explicit configuration and may incur additional costs or licensing fees. Cloud environments operate under a shared responsibility model, where providers are typically responsible for infrastructure security, physical hardware, and software updates, while customers are accountable for data encryption, identity and access management (IAM), and application-level security. These responsibilities vary depending on the cloud service model—Infrastructure as a Service (IaaS), Platform as a Service (PaaS), or Software as a Service (SaaS)—with customers typically having more control and responsibility in IaaS environments and progressively less in PaaS and SaaS models, often trading control for convenience and managed services. == Adoption and suitability == The decision to adopt cloud computing or maintain on-premises infrastructure depends on factors such as scalability, cost structure, latency requirements, regulatory constraints, and infrastructure customization. Organizations with variable or unpredictable workloads, limited capital for upfront investments, or a focus on rapid scalability benefit from cloud adoption. Startups, SaaS companies, and e-commerce platforms often prefer the pay-as-you-go operational expenditure (OpEx) model of cloud infrastructure. Additionally, companies prioritizing global accessibility, remote workforce enablement, disaster recovery, and leveraging advanced services such as AI/ML and analytics are well-suited for the cloud. In recent years, some cloud providers have started offering specialized services for high-performance computing and low-latency applications, addressing some use cases previously exclusive to on-premises setups. On the other hand, organizations with strict regulatory requirements, highly predictable workloads, or reliance on deeply integrated legacy systems may find cloud infrastructure less suitable. Businesses in industries like defense, government, or those handling highly sensitive data often favor on-premises setups for greater control and data sovereignty. Additionally, companies with ultra-low latency requirements, such as high-frequency trading (HFT) firms, rely on custom hardware (e.g., FPGAs) and physical proximity to exchanges, which most cloud providers cannot fully replicate despite recent advancements. Similarly, tech giants like Google, Meta, and Amazon build their own data centers due to economies of scale, predictable workloads, and the ability to customize hardware and network infrastructure for optimal efficiency. However, these companies also use cloud services selectively for certain workloads and applications where it aligns with their operational needs. In practice, many organizations are increasingly adopting hybrid cloud architectures, combining on-premises infrastructure with cloud services. This approach allows businesses to balance scalability, cost-effectiveness, and control, offering the benefits of both deployment models while mitigating their respective limitations. == Challenges and limitations == One of the primary challenges of cloud computing, compared with traditional on-premises systems, is maintaining data security and privacy. Cloud users entrust their sensitive data to third-party providers, who may not have adequate measures to protect it from unau
Agentic commerce
Agentic commerce (also referred to as agent-based commerce) describes an emerging form of e-commerce in which autonomous artificial intelligence (AI) agents independently execute purchasing and payment processes on behalf of users or organizations. Unlike conventional digital commerce systems, which require direct human interaction at key decision points, agentic commerce systems are designed to search for products or services, evaluate options, make purchasing decisions, and complete payments without real-time human involvement. An emerging development within the broader fields of e-commerce, fintech, and artificial intelligence; agentic commerce combines advances in generative AI, autonomous agents, application programming interfaces (APIs), and digital payment infrastructures to direct transactions with no direct human interaction. == Characteristics == A defining feature of agentic commerce is the delegation of end-to-end commercial activities to software agents. These agents typically operate according to predefined user preferences, rules, or constraints, such as price limits, quality criteria, delivery times, or preferred payment methods. Based on these parameters, an agent can autonomously perform tasks including product discovery, price comparison, contract selection, order placement, and payment execution. In contrast to decision-support systems, which provide recommendations to human users, agentic commerce systems are designed to act independently. Human involvement may be limited to initial configuration, periodic supervision, or exception handling. == Comparison with traditional and AI-assisted commerce == Traditional e-commerce requires users to manually browse products, select offers, and authorize payments. Generative AI systems used in commerce commonly assist users by answering questions or suggesting options, and do not complete transactions autonomously. Agentic commerce differs in that decision-making authority is partially or fully transferred to AI agents. As a result, the conventional customer journey, characterized by conscious decision points, may be replaced by continuous, automated micro-decisions performed by software. == Applications and business use cases == Potential applications of agentic commerce include recurring purchases, subscription management, business-to-business procurement, inventory replenishment, and price monitoring. In such contexts, transactions are often predictable and standardized, making them suitable for automation. From a business perspective, agentic commerce systems may be used to optimize supply chains, manage inventory levels, negotiate prices algorithmically, or execute transactions across multiple platforms. Enterprises adopting the new technology include retailers Walmart, Home Depot, Wayfair and Urban Outfitters, and ad tech DSPs, including Google Ads, Amazon, and Yahoo. Chinese tech firms are using apps to provide full-service shopping and payment tools. These includes Alibaba, Tencent, and ByteDance who are currently developing AI powered shopping apps. The Qwen AI chatbot allows users to complete transactions directly within its interface. US firms are still leading in developing AI models but integration is slower due to privacy restrictions. == Payments and technical infrastructure == Agentic commerce relies on digital payment systems capable of supporting automated, machine-initiated transactions, including API-based payment processing, tokenization, real-time authorization, and continuous risk monitoring. Typical user interfaces, such as shopping carts, may be replaced by backend integrations between AI agents, merchants, and payment service providers. For example, Iike 2025, Alibaba launched Alipay AI Pay, which grew and began operating as an application for different retailers. In December 2025, Alipay teamed up with Rokid to enable developers to integrate AI payments into AI agents on Rokid's Lingzhu platform. In January 2025, Alipay unveiled the Agentic Commerce Trust Protocol in partnership with Alibaba's consumer AI applications, such as the Qwen App and Taobao Instant Commerce. Qwen adopted the platform first, connecting it to Taobao Instant Commerce and Alipay AI Pay. Users could use Qwen's agentic feature to place food and drink orders within the application instead of having to click outside to an external browser. For merchants, participation in agentic commerce may require products and services to be presented in structured, machine-readable formats to ensure discoverability and interoperability with autonomous agents. == Universal Commerce Protocol (UCP) == In January 2026, Google announced the Universal Commerce Protocol (UCP), an open-source web standard intended to enable interoperability between AI agents and retail systems across the shopping journey, from discovery and checkout to post-purchase support. UCP makes use of REST, JSON-RPC transports, and support for Agent Payments Protocol (AP2), Agent2Agent (A2A), and Model Context Protocol (MCP). == Legal, regulatory, and security considerations == The use of autonomous agents in commerce raises legal and regulatory questions, particularly regarding authorization, liability, consumer protection, and fraud prevention. Existing payment and contract frameworks are generally based on human decision-makers, and their applicability to autonomous agents remains an area of active discussion. Open issues include responsibility for unauthorized or erroneous transactions, mechanisms for dispute resolution, standards for agent authentication, and compliance with data protection and financial regulations. Continuous, automated transaction patterns may also require new approaches to security and risk assessment. Traditional fraud models centered on identity verification may be insufficient for agentic commerce, and that merchants may need intent-based detection methods using machine learning and behavioral analysis to distinguish legitimate AI agents from malicious automation. === Governance frameworks === The deployment of autonomous AI agents in commercial environments has prompted the development of dedicated governance frameworks. These aim to define operational boundaries, decision authority, oversight mechanisms, and accountability structures for agentic systems. The Agentic Commerce Framework (ACF), created in 2025 by Vincent Dorange, is a governance standard that structures the deployment of autonomous AI agents around four founding principles (Decision Sovereignty, Governance by Design, Ultimate Human Control, Traceable Accountability), four operational layers, and 18 governance KPIs. In January 2026, Singapore's Infocomm Media Development Authority (IMDA) published the Model AI Governance Framework for Agentic AI, extending its existing AI governance guidelines to address agent-specific risks including delegation chains and multi-agent coordination. The Cloud Security Alliance (CSA) has also proposed an Agentic Trust Framework applying zero-trust principles to AI agent governance. == Ecosystem and implementation == The adoption of agentic commerce typically requires changes in commerce architecture, data modeling, identity and permissions, and API-based orchestration of checkout and post-purchase workflows. Management consultancies have identified agentic commerce as a structural evolution of digital commerce, emphasizing the role of AI-driven agents in automating discovery, decision-making, and transaction processes across commerce systems. McKinsey & Company has described agentic commerce as a significant shift in how consumers interact with brands and how enterprises design their commerce operating models. In Europe, this ecosystem also includes digital commerce consultancies specializing in the adoption of agentic commerce. Consulting firms such as Horrea support brands in understanding and implementing the technological and organizational shifts associated with agentic commerce. == Market development and outlook == Agentic commerce is generally regarded as an early-stage development. Industry analysts have projected that AI-driven agents could account for a small but growing share of digital payment transactions within the coming years. Due to the scale of global digital commerce, even limited adoption could represent substantial transaction volumes. Analysts expect that by 2029, AI agents could handle between 1% and 4% of all digital payment transactions. With a projected total transaction volume of over $36 trillion a year, even a small share translates into a market worth up to $1.47 trillion. According to a McKinsey study from October 2025, agentic commerce projects that by 2030, the U.S. business-to-consumer retail market alone could see up to $1 trillion in revenue orchestrated through agentic commerce. On a global scale, the opportunity could range from $3 trillion to $5 trillion. Early experiments and pilot projects have demonstrated both the potential and current limitations of the