JosephCottam
commented
10 years ago I have sneaking suspicion the real answer is to have two different transfer algorithm types:
- Local -- Just accesses X/Y passed
- Bulk -- May look at multiple locations
The renderer may use different algorithms for the two different types...
The transfer combinators over-cache the intermediate aggregates. They cache aggregates because any given transfer MIGHT look at neighborhoods of values, so to present a consistent view, the many combinators compute the whole space on the first input then just return values from the cached computation.
This strategy is inefficient when the actual transfer does not look at the neighborhood. It takes up memory AND it incurs synchronization overheads...
Because combinators are themselves transfer functions, reporting has to be runtime modifiable. Requires reporting properties (e.g., isSimple() returns true iff only the exact XY will be accessed) or some fancy work in the type hierarchy...
Storing the input values on specialization is not the right tack because then the transfer would only be valid for working with the original input. At a minimum it would break the 'enhance' button.