askee

It's also about performance. The snippet assumes the byte order of the buffer or byte stream is little endian so only covers two of four cases. If you want to read a little-endian byte stream on a big-endian machine, of course you need swapping. But, considering portability, if that byte stream had been written by the big-endian machine before (or came directly from network) it would be in big-endian ordering and swapping would be wrong.

Assuming LE ordering on the writer side, you would need to swap again on a BE machine. Usually, however, you want to store in your target byte order, though. One could argue this is irrelevant as long as the memory doesn't leave your application, of course. Yet, by explicitly having macros _to_cpu, _to_be, _to_le and so on you make all of this explicit.

Wasn't the mostly unanimous agreement in this thread that this paper was of low quality and its conclusions are questionable at best?

Also, it's "deus absconditus" not "abscondidus" in 1.

The k'th largest element in an array can also be found by the nth_element() algorithm already included in the STL. It has linear complexity as opposed to the O(n log k) and O(k log n) variants proposed here.

How good does it work with non-natural images where rows/columns are not similar to each other? White noise for example should prove rather difficult.

No it doesn't, unfortunately. I misunderstood OP's questions at first. You can connect owncloud to a mail server (a la Roundcube) but nothing more.

Self-hosted owncloud works for me except for the gruesome woes every single time I try to update it.

You would solve e.g.

min_x* ( ||A x* - b|| (+\lamba regularization(x*) )

In general there are no shortcuts, and when the matrix A is not small (e.g. m x n with m,n << 100), you don't want to invert A, especially if you are only interested in x (from A x = b). Instead, use numerical minimization schemes like conjugated gradients and variants thereof or Quasi-Newton methods (BFGS). Combined with preconditioning as well as regularization or denoising this usually yields good results. Compressive sampling methods (total variation regularization) have received lots of attention in the last ten years.

I find the wording somewhat peculiar: 'the resulting address will change dramatically, by (4 - 2^(32+2)). In 32-bit mode (all addresses modulo 2^32), this is just an increase by 4 as usual; the "wraparound" part is a multiple of 2^32 and hence invisible'

Why would it matter that the address will change "dramatically"? Even if it didn't (and only change by say 16 bytes or whatever) you'd have to deal with it. The problem is that int overflows at 2^31 while long/a larger type doesn't. In order to cope with the overflow you'll have to "simulate" an overflow in the larger type as well (or at least do what the smaller type does) which is achieved via a sign-extend.

Rasterization also is of highly-parallelizable nature and this parallelism has been exploited to great effect in the last decade(s). Given that Ray Tracing's only advantage over Rasterization is specular reflection it seems unlikely it is really superior in terms of efficiency. Especially since specular reflections and many other effects can be achieved via cheating in Rasterization.

For real GI, Path Tracing, Photon Mapping and so on are the methods of choice and not Ray Tracing.

GCC already has something alike, the parallel mode [1]. It is based on the Multi-Core STL (MCSTL) developed at Karlsruhe University. In [2] you can also find some publications. As far as I know this already works quite well.

[1] https://gcc.gnu.org/onlinedocs/libstdc++/manual/parallel_mod... [2] http://algo2.iti.kit.edu/singler/mcstl/

> The important upside is that SV is the center of the universe for interesting computer science work.

This is so true! (Even by my limited experience) Comparing job offerings in my home area vs offerings of any random company in the valley, the SV company wins. It's unbelievable how few interesting CS jobs there are in the rest of the world in comparison.