[justifier]

then you'd debug it, or program debuggers to flit around looking for programmer error then address it

the system is clear about its capabilities regarding 'correctness'

which seems to imply the programmer's job is to optimise with those built in inaccuracies

but what those inaccuracies afford is what ackley is calling robustness and indefinite scalability

ackley addresses your question directly with a sorting comparison(o) from a later video

the graph fails to exhibit where maxwell's demon(i) horde sort would express itself on the graph, but sorting corruption is addressed in the paper(ii)

    The demon horde sort’s performance may be just adequate,
    by that measure, but its robustness seems quite impressive.
    
    Figure 23 shows results of one experiment in which we
    randomly corrupted site memory with simulated bit errors at
    a range of probabilities. Each error occurrence selects a random
    site and then flips from one to eight of its 64 atomic bits.
    
    We can see that while channel length helps performance, it
    does not help robustness against this system perturbation—
    but the system is strikingly robust anyway, tolerating upward
    of 10 multibit corruptions per million events with essentially
    no visible performance degradation, regardless of channel
    length.

    Above about 50 errors/Mevent the system reliably falls
    apart—and the pathology appears to run a reliable course..

unintended performance appears to be the reason for the advent of this system

but going further as to deal with unintended performance of hardware

if you have a multi core system running an incorrectly programmed sort and one core fails the whole thing shuts down, but an incorrectly programmed sorter in the demon horde will keep functioning even with failed cores, affording the opportunity to adjust while performing

(o) https://youtu.be/7hwO8Q_TyCA?t=688

(i) https://en.wikipedia.org/wiki/Maxwell%27s_demon

(ii) http://comjnl.oxfordjournals.org/content/56/12/1450.full.pdf...