Gist de70ab070f96fd7c413f

100%

Gist de70ab070f96fd7c413f

✓ Published0🌍 Public

Last edited Oct 31, 2015

Created on Oct 31, 2015

This GAMA model benchmarks four spatial query methods—`closestTo`, `optimClosestTo`, `minDistance`, and `basicClosestTo`—across varying agent population sizes and geometry usage. It compares execution times for high- and low-caller/called agent counts, with optional circular geometries for agents, using `machine_time` for timing. The simulation outputs performance ratios per cycle, demonstrating how each method scales under different spatial configurations and query loads.

AI-generated description

Similar vizzes

Loading thumbnail…

Wrong performances of the closest_to operator in Gama 1.7 (dev)

This example benchmarks the performance of three different methods for finding the nearest neighbor among agents in the Gama 1.7 platform: the built-in `closest_to` operator, an optimized variant using `at_distance`, and a manual `minDistance` calculation via distance collection. It measures execution time across four population-size scenarios, from 100 to 10,000 calling and called agents, writing the results to the console. The code uses Gama’s agent-based modeling API, including `create`, `ask`, `machine_time`, and spatial queries like `closest_to` and `at_distance`. The visualization demonstrates how algorithmic choice and agent density affect computational performance.

RRCura

81% match

Loading thumbnail…

Gist 294bf474d3283271f3e967f4e15f0d03

This example runs a sensitivity analysis on a GAMA agent-based model, testing a wide range of parameter values to assess their influence on simulation outcomes. It defines dozens of parameter ranges (e.g., distances, probabilities, counts) via R’s `seq()` function, then generates an XML experiment plan for headless GAMA simulations, launched in parallel across 24 cores using a Bash script with `taskset`. The visualization itself is not produced here; the code focuses on experimental setup and parameter sampling.

RRCura

64% match

Loading thumbnail…

Gama : batch mode errors

This example compares two GAMA batch-mode experiments, “Bugged” and “Working,” that simulate a simple infection spreading among 300 moving people. It shows how a subtle output error—plotting the count of immune agents instead of infected ones—yields a misleading chart, while the corrected version tracks the actual infection count. Both experiments use GAMA’s `chart` display with a series type and `value:` data source, repeated five times with fixed seeds. The model relies on GAMA’s `people` species with `skills:[moving]` and the `wander` reflex for spatial dynamics.

RRCura

52% match

Loading thumbnail…

Gist 877801

This example demonstrates a debugging session for a geospatial query on a Portland crime database using MongoDB. The visualization is not a traditional chart but rather a log of command-line interactions in the MongoDB shell, revealing a critical bug in the `geoNear` command with spherical geometry. The author, Caged, queries crime records at a specific latitude/longitude coordinate and discovers that `$centerSphere` queries return no results due to a "spherical distance would require wrapping" error, while a `geoNear` command returns records at a distance of 1.803 even for the exact same location. The gist highlights the inconsistency and potential bug in MongoDB's spherical distance calculations, where identical coordinates yield non-zero distances. The visualization would likely plot these crime locations on a map, with a note or highlight on the unexpected distance value, illustrating the importance of accurate geospatial querying and the quirks of early MongoDB versions.

CCaged

52% match

Loading thumbnail…

Cypher for Spatial

This example demonstrates the spatial capabilities of Neo4j’s Cypher query language by finding the nearest city to a given point in Germany. It shows how to combine geographic coordinates with graph traversal to return a ranked list of nearby cities, ordered by distance. The visualization uses `spatial.closest` from the Neo4j Spatial library, with a query that computes distances via the `distance()` function in kilometers. The accompanying data files include a GeoJSON point for the starting location and an exported CSV of city names with distances, while the code references adding a layer and populating it with cities from a Gist. The result is a straightforward map-based proximity search, rendered as a tabular list rather than a graphical map.

CCliffordAnderson

51% match

Loading thumbnail…

Comparing the performances of various DBMS using dplyr for large-ish data

This example compares the execution times of data manipulation operations across different database management systems using the `dplyr` and `dbplyr` R packages. It benchmarks a `group_by` with `summarise` and a `left_join` with `mutate` on a 50-million-row tibble, running the same queries against in-memory data frames, SQLite databases (in-memory and file-based), and PostgreSQL. The code uses `system.time` to measure the elapsed user and system times for each operation, recording results in a benchmark summary table. The visualization highlights performance differences across database backends for typical data wrangling tasks.

RRCura

50% match

Loading thumbnail…

Gist e92adbf79e3256a0d3e222f140a0433b

This example visualizes the relative performance of 16 JavaScript event-emitter libraries across two benchmark scenarios, “emit objects” and “emit one parameter,” using the raw output of the benchmark runner. The data, drawn from a gist by Hypercubed, is rendered as a grouped horizontal bar chart where each bar’s length corresponds to operations per second (ops/sec), with libraries sorted by speed and the fastest highlighted. The chart uses a simple SVG-based custom layout (likely with d3-scale for axes and d3-array for sorting) rather than a high-level charting library, directly mapping the numeric values to pixel widths. The visualization does not show error margins or statistical significance, only the raw ops/sec values and the benchmark’s “Fastest is” annotation for each test.

HHypercubed

50% match

Loading thumbnail…

Gist 652595e55960a8e04a29

This example visualizes the spatial relationships between metropolitan statistical areas and their constituent counties, townships, and other administrative geometries. The code first builds a combined geometry table using SQL, merging overlapping regions across multiple spatial layers while excluding special cases like Boston. It then renders these shapes using D3.js, likely leveraging `d3.geoPath` for projection and canvas or SVG drawing. The query explicitly handles hierarchical and overlapping geographies, prioritizing township-level detail where available and falling back to county unions for other areas. The final visualization shows how different government boundaries interlock within U.S. metropolitan regions, with the SQL preprocessing ensuring no duplicated or missing polygons.

CCaged

50% match