vnormalize (<0, 0, 0>) isn't matematically defined... but POV-Ray 3.1a
(windows) returns a "perfectly valid" <nan, nan, nan> vector... it's a sin
that there isn't any IsNan() function or something like that to recognize
it. And if i use this vector in any object the perser locks only while
creating light buffers.
I think vnormalize (<0, 0, 0>) should return an error in parsing time, and
POV should be compiled ignoring them.

Post a reply to this message

In article <3714a7c6.0@news.povray.org> , "Daniele Varrazzo" <piro at 
officine dot it> wrote:

> vnormalize (<0, 0, 0>) isn't matematically defined... but POV-Ray 3.1a
> (windows) returns a "perfectly valid" <nan, nan, nan> vector... it's a sin
> that there isn't any IsNan() function or something like that to recognize
> it.

There is!

#declare myvector = <0,0,0>

#if((myvector.x == 0) && (myvector.y == 0) && (myvector.z == 0))
#error "Error"
#endif


     Thorsten

Post a reply to this message

In povray.general "Daniele Varrazzo" <piro at officine dot it> wrote:
: vnormalize (<0, 0, 0>) isn't matematically defined... but POV-Ray 3.1a
: (windows) returns a "perfectly valid" <nan, nan, nan> vector... it's a sin
: that there isn't any IsNan() function or something like that to recognize
: it.

  I think that's because it's system dependant. Recognizing NaN-values
would make it non-portable.
  In many systems this kind of mathematical operation will just crash
the program.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Why not do something like this ?

#macro vnorm(vV)
  #if(vV=<0,0,0>)
    (<0,0,0>)
  #else
    vnormalize(vV)
  #end
#end

Daniele Varrazzo wrote:
> 
> vnormalize (<0, 0, 0>) isn't matematically defined... but POV-Ray 3.1a
> (windows) returns a "perfectly valid" <nan, nan, nan> vector... it's a sin
> that there isn't any IsNan() function or something like that to recognize
> it. And if i use this vector in any object the perser locks only while
> creating light buffers.
> I think vnormalize (<0, 0, 0>) should return an error in parsing time, and
> POV should be compiled ignoring them.

-- 
//Spider
        [ spi### [at] bahnhofse ]-[ http://www.bahnhof.se/~spider/ ]
What I can do and what I could do, I just don't know anymore
                "Marian"
        By: "Sisters Of Mercy"

Post a reply to this message

or even better.
#macro vnorm(vV)
  #if(vV=<0,0,0>)
    #error "Normalize of <0,0,0>"
  #else
    vnormalize(vV)
  #end
#end

Spider wrote:
> 
> Why not do something like this ?
> 
> #macro vnorm(vV)
>   #if(vV=<0,0,0>)
>     (<0,0,0>)
>   #else
>     vnormalize(vV)
>   #end
> #end
> 
> Daniele Varrazzo wrote:
> >
> > vnormalize (<0, 0, 0>) isn't matematically defined... but POV-Ray 3.1a
> > (windows) returns a "perfectly valid" <nan, nan, nan> vector... it's a sin
> > that there isn't any IsNan() function or something like that to recognize
> > it. And if i use this vector in any object the perser locks only while
> > creating light buffers.
> > I think vnormalize (<0, 0, 0>) should return an error in parsing time, and
> > POV should be compiled ignoring them.
> 
> --
> //Spider
>         [ spi### [at] bahnhofse ]-[ http://www.bahnhof.se/~spider/ ]
> What I can do and what I could do, I just don't know anymore
>                 "Marian"
>         By: "Sisters Of Mercy"

-- 
//Spider
        [ spi### [at] bahnhofse ]-[ http://www.bahnhof.se/~spider/ ]
What I can do and what I could do, I just don't know anymore
                "Marian"
        By: "Sisters Of Mercy"

Post a reply to this message

>  I think that's because it's system dependant. Recognizing NaN-values
>would make it non-portable.
I know it... i don't want an IsNan: i'd like that vnormalize(<0,0,0>) should
always return an error, just like sqrt(-1). So it should 1/0 or 0/0 (that
are two very different things).

I know that nan is compiler-dependant. That's why none of the compiler
should admit it!

All the system such as #if (vV=<0,0,0>) are all nice systems to avoid
troubles... but are SLOW because a POV-Ray scene is not a compiled and
optimized language, but just parsed-on-the-fly code. The parser should make
all the controls it needs to render a proper scene and leave the user no
chance but a renderable code.

Povray cries loud if i access the tenth element of a 5 elements array... i
(matematically) cry louder if somebody ask me the direction of a zero length
vector!

I never used a nan-able compiler, but i think enabling it is just a compiler
option, such out of bound array controls or something else. Can't it be
disabled?
Daniele.

Post a reply to this message