Comment Re:Amd also has better MB's for the price (Score 1) 104
PS. If you still want an Intel, the Xeon E3 1200 series is the closest ECC chipset to a desktop chipset.
Well, remember this is Jeopardy, so the contestants receive the 'answer,' and must supply the 'question.'
Actually, you answer the question just like any other game show. The cute oddity of Jeopardy is that you frame your answer in the form of a question. Have no doubt though, you are most definitely giving an answer.
If you watch a lot of Jeopardy you will notice that when a contestant fails to give the answer in the proper form Alex will say, "I'm sorry. You failed to give your answer in the form of a question." I am quite confident that Alex will never say, "I'm sorry. You failed to give your question to the answer."
And now, just to blow your mind.
Q. The form of an answer on Jeopardy.
A. What is a question?
with C++ it's not always obvious what a compiler might want to do with '+' thanks to operator overloading and rather convoluted implicit casting rules.
I agree that optimized, compiled code might as well be a block box nowadays.
However, I think the problem with C++ is that it is not obvious what your fellow _programmer_ wants to do with '+'. That's the real problem with operator overloading. Everytime I have to dive through 4 layers of pre-processed headers to figure out what '+' does is another nail in that coffin.
1. Immediate lighting rasterizer = O(S*N*L)
2. Deferred lighting rasterizter =O(S*N)+O(S*L)
3. Ray tracer = O(S*log N*L*D)
where N is the number of solid 3D elements, L is the number of direct illumination lights, D is the indirect lighting depth and S is the number of screen elements.
No matter how I look at this, ray tracing is not very compelling.
Once upon a time, we thought ray tracers were fast. If we hold screen size as a constant and set the number of bounces to 1 for a fair comparison to a 1992 era rasterizer we get the "classic" complexity analysis comparison.
1. Rasterizer = O(N*L)
2. Ray tracer = O(log N*L)
Winner: ray tracer. However, a few things have changed since 1992. First, screen size is important and should not be ignored. This is due to the increasing importance of screen space effects. Second, deferred lighting broke rasterization in half. Third, rasterizers can now do convincing shadows and fake global illumination. So, to keep up with the quality of the average 2010 rasterizer we have to set D>1. This is a 1-2-3 knockout combo for ray tracers.
Rasterizers are the current complexity king. Now, I'll tell you why it will remain the king. Ray tracers have an architecturally bad design. It looks like this:
for p in rays:
for i in items: raytest
for s in lights:
for t in bounces:
There is a beautiful elegance to this. It is a good way to learn how to do computer graphics. Unfortunately, this kind of architecture always leads to bad complexity that looks like this: O(f1*f2*f3*f4
Rasterizers have a better basic architecture. Scatter-gather type architecture tends to lead to nice complexity like this: O(f1)+O(f2)+O(f3)+O(f4). Don't take my word for it, look at the history. The O(N*L) immediate rasterizer got broken up into the O(N)+O(L) deferred rasterizer as soon as enough memory became available. Indirect lighting followed the same pattern.
I'm not saying that ray tracers will always be slow. But, I _am_ saying that if ray tracers ever become fast again, it will be because they have been architecturally restructured into something that looks a lot like a rasterizer. In such a case, any claimed victory by the ray tracer would be a pyrrhic one.
I have hardly ever known a mathematician who was capable of reasoning. -- Plato