Xah Lee wrote:
> I didn't realize until after a hour, that if Jon simply give numerical
> arguments to Main and Create, the result timing by a factor of 0.3 of
> original. What a incredible sloppiness! and he intended this to show
> Mathematica speed with this code?
>
> The Main[] function calls Create. The create has 3 parameters: level,
> c, and r. The level is a integer for the recursive level of
> raytracing . The c is a vector for sphere center i presume. The r is
> radius of the sphere. His input has c and r as integers, and this in
> Mathematica means computation with exact arithmetics (and automatic
> kicks into infinite precision if necessary). Changing c and r to float
> immediately reduced the timing to 0.3 of original.
That is only true if you solve a completely different and vastly simpler
problem, which I see you have (see below).
> The RaySphere function contain codes that does symbolic computation by
> calling Im, which is the imaginary part of a complex number!! and if
> so, it returns the symbol Infinity! The possible result of Infinity is
> significant because it is used in Intersect to do a numerical
> comparison in a If statement. So, here in these deep loops,
> Mathematica's symbolic computation is used for numerical purposes!
Infinity is a floating point number.
> So, first optimization at the superficial code form level is to get
> rid of this symbolic computation.
That does not speed up the original computation.
> Instead of checking whethere his “disc = Sqrt[b^2 - v.v + r^2]” has
> imaginary part, one simply check whether the argument to sqrt is
> negative.
That does not speed up the original computation.
> after getting rid of the symbolic computation, i made the RaySphere
> function to be a Compiled function.
That should improve performance but the Mathematica remains well over five
orders of magnitude slower than OCaml, Haskell, Scheme, C, C++, Fortran,
Java and even Lisp!
> Besides the above basic things, there are several aspects that his
> code can improve in speed. For example, he used pattern matching to do
> core loops.
> e.g. Intersect[o_, d_][{lambda_, n_}, Bound[c_, r_, s_]]
>
> any Mathematica expert knows that this is something you don't want to
> do if it is used in a core loop. Instead of pattern matching, one can
> change the form to Function and it'll speed up.
Your code does not implement this change.
> Also, he used “Block”, which is designed for local variables and the
> scope is dynamic scope. However the local vars used in this are local
> constants. A proper code would use “With” instead. (in lisp, this is
> various let, let*. Lispers here can imagine how lousy the code is
> now.)
Earlier, you said that "Module" should be used. Now you say "With". Which is
it and why?
Your code does not implement this change either.
> Here's a improved code. The timing of this code is about 0.2 of the
> original.
> ...
> Timing[Export["image.pgm",[EMAIL PROTECTED]@Main[2,100,4.]]]
You have only observed a speedup because you have drastically simplified the
scene being rendered. Specifically, the scene I gave contained over 80,000
spheres but you are benchmarking with only 5 spheres and half of the image
is blank!
Using nine levels of spheres as I requested originally, your version is not
measurably faster at all.
Perhaps you should give a refund?
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
--
http://mail.python.org/mailman/listinfo/python-list
