This is a somewhat comical statement in a thread about "Rewrite it in Rust."

But, let's assume for the sake of argument that your analogy is the correct one. You know where they assume that if you don't let the police search your house, or if you don't answer police questions, you must be guilty? China.

So, we can just as easily judge the Chinese government by another heuristic: The Golden Rule

So, while we may not be able to know for sure how COVID-19 originated, we can certainly draw an adverse inference from the behavior of the Chinese government.

[1] https://en.wikipedia.org/wiki/Adverse_inference

Chrome already does this.

[1] should be -std=c99

  template
  class SoA : public tuple...> {
          // ...
          template
          tuple subscript(size_t i, index_sequence) {
                  return {get(*this)[i]...};
          }
  public:
          // ...
          auto operator[](size_t i) {
                  return subscript(i, index_sequence_for{});
          }
  };

In idealized algorithmic analysis, but not necessarily real life. "Amortized O(1)," which I assume you concede is a commonly-used, meaningful and legitimate term, means "technically" an idealized O(>1) but O(1) in practice.

Calling memcpy inside a Ruby method call is amortized O(1) because for any "n" that fits within available memory, it will always be much faster than the other things in a Ruby method call, which involve dozens of locks, hash table lookups with string keys, dynamic type checks, additional Ruby method calls and so forth.

Likewise, computational complexity on an idealized Von Neumann machine isn't always the same on a real computer, in both directions. Dynamic allocations are theoretically O(n) but may be O(1) if the program never exceeds the preallocated space. Or suppose there were a loop over an array of pointers which dereferenced each pointer; the dereferences are theoretically O(1) but may be O(n) if they evict the parent array from the cache.

> What is the common case in your view?

Such as an array small enough that it can be copied with 10 or fewer vector load/stores.

> O(3n) = O(2n) = O(n)

Yes, that's my point. It's impossible to implement the example in less than idealized O(n) time, so O(n) and O(1) operations are equivalent complexity-wise WRT the entire method.

That's just a lock (nontrivial but O(1)) and a memcpy (technically O(n) but trivial, and O(1) for the common case if it's implemented with vector instructions), plus in any event the sums-of-neighbors method has to be at least O(n) on an idealized Von Neumann machine because it must read every element of the source array and also write every element of the destination.

  class Array
    def neighbor_sums
      map.with_index do |_, i|
        fetch(i - 1 & 0xFF_FF_FF_FF, 0) + fetch(i + 1, 0)
      end
    end
  end

  [1, 1, 1, 1].neighbor_sums # [1, 2, 2, 1]

  ios::sync_with_stdio(false);