This is a somewhat comical statement in a thread about "Rewrite it in Rust."
1,770 karma · joined March 26, 2015
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.
Chrome already does this.
[1] should be -std=c99
template<typename... Ts>
class SoA : public tuple<vector<Ts>...> {
// ...
template<size_t... Is>
tuple<Ts&...> subscript(size_t i, index_sequence<Is...>) {
return {get<Is>(*this)[i]...};
}
public:
// ...
auto operator[](size_t i) {
return subscript(i, index_sequence_for<Ts...>{});
}
};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);
https://en.cppreference.com/w/cpp/io/ios_base/sync_with_stdi...But the edit window had passed by the time I changed it.
I changed it to a relatively KISS and IMO genuinely beautiful version in the parent, for others' benefits here's the version you were referring to in the above comment:
#!/usr/bin/env ruby
# frozen_string_literal: true
module FizzBuzz
Integer.include self
def self.array(enumerable = 1..100)
enumerable.map(&:to_fizzbuzz)
end
def to_fizzbuzz
"#{:Fizz if (self % 3).zero?}"\
"#{:Buzz if (self % 5).zero?}"
.then
.find { |s| !s.empty? } || to_s
end
end
puts FizzBuzz.array #!/usr/bin/env ruby
puts((1..100).map do |n|
"#{:Fizz if (n % 3).zero?}"\
"#{:Buzz if (n % 5).zero?}"
.then
.find { |s| !s.empty? } || n
end)I think he meant beautiful in the conceptual sense (e.g. a beautiful algorithm) not the aesthetic sense.
Aesthetically speaking, Ruby would definitely be in my top 3 and possibly first. For me its main competition is ML-syntax languages, in particular Standard ML and F#.
ETA: Getting your employer to pay your company instead of you would be tax fraud.
This is illegal.
https://www.blog.google/products/gmail/subject-write-emails-...