Jaime Vives Piqueres <jai### [at] ignoranciaorg> wrote:
>   Oh... well, if you use vstr() with vnormalize(<0,0,0>), you will se it 
> returns a vector <nan,nan,nan>. If you look also at the docs, the 
> description for vnormalize() "criptically" states that "vnormalize(<0,0,0>) 
> will not give a usefull result". This sounds more like an undesired side 
> effect than a bug... and from the docs wording I can supose there is no 
> easy solution for the problem. Note this sentence was not on the 3.1 docs, 
> so I suspect it was discussed on a previous bug report...

  This is a case where there's no simple solution, even though it could
look like that at first glance.

  Some people think that vnormalize(<0,0,0>) should return <0,0,0>.
That's *not* a good solution because it breaks the very definition of
vnormalize. vnormalize is defined to always return a vector of lenght 1,
which <0,0,0> is not. If you trust that it always returns a vector of
that length but there's a special case where it doesn't, then you can't
trust it anymore.

  The best solution is, of course, that POV-Ray would issue an error if
a 0-vector is normalized (because it can't). Getting a clear error message
is always better than getting a weird result.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message