Data and scape engine operators. 

Data engine creates forms of memory specificed by a "word-spec" 

The data engine is the "memory" of the ceptr VM, it's just that there are lots of types of memory, not just RAM accessible by word-sized int.  Instead the machine "word" can be semantic structures, stored natively.

Sort/Limit are kinds of meta-geometry functions on scapes

Geometry functions from spreadsheet, (structural and contextual): existance, isometric maps, next/prev,  orderded, bounded, linearity, rotational, continuous vs stepped, tree, etc..

Find: search on data that's allready scaped so it can be retrieved via random access

Match: requires iteration and processing.

We took a long walk and explored the issues of "variable equality" in scapes. What it would mean to provide "=" functions that may operate differently at different "resolutions" of scapes. Think of different zoom levels on a map where you'd say two people live in the "same" place at the level of country/bioregion/city/neighborhood/street etc. based on the level of resolution you're working with.

In hindsight, it seems obvious, if scapes are used for fractal sense-making and coherence, that native support different resolutions, as well as different modes of comparison, are necessary.

Also... related to "equality" and "resolution" is the notion as edges as gradients. That boundary patterns may emerge in a post-hoc fashion based on rates of change (density of gradient). There may be ways to detect edges in gradients by watching rate of change of the gradient values.

Emergent low resolution scapes should be able to be built out of high resolution scapes via the expressive capacity, and thus provide "quantum" or highly meaningful resolutions.

Reminder:

 - Contextual geometry is to do with relationships within the content of the DATA.

 - Structural geometry is to do with relationships within the structure of the KEYS (or indexing functions).