Hi all,

with all due respect to the amount of work the team has put into
this software ( and is still putting into, of course ) I can't refrain
from stating that I don't like two changes that have been made:

- removing an operator in release candidate (!) #6 (^)
- the often discussed problem about vnormalize( <0,0,0> ) = 0

The second issue breaks probably thousands of scenes, so it should be
at least mentioned in the chapter about "changed features that may break old
scenes". I think that quite a few people have written ( or are writing right
now ) macros to reproduce the old behaviour. I propose to add such a macro
to an appropriate include file ( or even better, reinstate old behaviour ;)

Greetings

Karl
--
The two most common things in the universe are hydrogen and stupidity.
(H.Ellison)

Post a reply to this message

In article <3d0ae109$1@news.povray.org> , "Karl J. Anders" 
<kar### [at] webde> wrote:

> with all due respect to the amount of work the team has put into
> this software ( and is still putting into, of course ) I can't refrain
> from stating that I don't like two changes that have been made:
>
> - removing an operator in release candidate (!) #6 (^)

This has been removed to avoid getting complaints from people who don't
understand that there can be more than one way how something works.  The
feature used to work one way and thus we got complaints from those favoring
the other way of operation.  Changing it would have resulted in the other
group complaining.  Others seemed to complain just for the sake of
complaining and they didn't mind the original (MegaPOV) implementation not
working different.  As the feature is redundant anyway and was only a 3.5
beta addition and was not in 3.1 it has been removed because we don't want
to have to waste our time with endless pointless discussions how it works
and how some people expect it to work.

> - the often discussed problem about vnormalize( <0,0,0> ) = 0
>
> The second issue breaks probably thousands of scenes, so it should be
> at least mentioned in the chapter about "changed features that may break old
> scenes". I think that quite a few people have written ( or are writing right
> now ) macros to reproduce the old behaviour. I propose to add such a macro
> to an appropriate include file ( or even better, reinstate old behaviour ;)

There was no old behavior.  There never was a legal result being returned
for a zero length vector and the documentation clearly stated it.  You
cannot normalize a zero length vector, it is undefined and always was.  The
problem was that the parser didn't catch this...


    Thorsten

____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povrayorg

I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

In article  <3d0af371@news.povray.org>, "Thorsten Froehlich" 
<tho### [at] trfde> wrote:


> (snip)
> As the feature is redundant anyway and was only a 3.5 beta addition ...
> (snip)

yeah, it is redundant, but I think "something^another" is easier to write
and read than "pow( something, another )". AND it is difficult to search and
replace that ;)

I understand that most of the discussion was about operator precedence,
which I thought odd from the beginning on, but of course there always are
people with different opinions ...

>
> There was no old behavior.

Sorry, but that's wrong! 3.1g (mac) at least did return <0,0,0> and no error
message - and this is, though mathematically definitely incorrect, quite
useful in many cases. And some include files from other people, like
TORSPLINE or CHEAP_SWEEP suddenly don't work as before :(

> There never was a legal result being returned for a zero length vector and the
> documentation clearly stated it.

Sorry, but no, it didn't ! It does so with all 3.5 betas, but not with 3.1g.

> You cannot normalize a zero length vector, it is undefined and always was.

Correct from a strictly mathematical point of view, but - as pointed out
above - a function that does return the normalized vector if possible and
<0,0,0> if not IS useful ...

> The problem was that the parser didn't catch this...
>
Shame :)

Don't get me wrong, I don't want to make anybody angry or step on someone's
toes, but I think you ( the team ) are behaving a bit inconsistently here :)
With vnormalize, you refer to strict mathematical reasons and ignore
discussion, with "^" you "fear" (sorry) discussion and throw it out instead
of simply DEFINING the way that operator behaves in POV-SDL ...

Well, that's the way it is, and it probably will not change again ;)

CU

Karl

--
The two most common things in the universe are hydrogen and stupidity.
(H.Ellison)

Post a reply to this message

Thorsten Froehlich wrote:
> 
> [...]
> 
> There was no old behavior.  There never was a legal result being returned
> for a zero length vector and the documentation clearly stated it.  You
> cannot normalize a zero length vector, it is undefined and always was.  The
> problem was that the parser didn't catch this...
> 

Are you sure about this?  I don't think vnormalize() should return zero
for a zero length vector, but the 3.1 source i have here says:

          case VNORMALIZE_TOKEN:
            Parse_Vector_Param(Vect);
            VLength(Val,Vect);
            if (Val==0.0)
            {
              Make_Vector(Vect,0.0,0.0,0.0);
            }
            else
            {
              VInverseScaleEq(Vect,Val);
            }
            break;


Christoph

-- 
POV-Ray tutorials, IsoWood include,                 
TransSkin and more: http://www.tu-bs.de/~y0013390/  
Last updated 14 Jun. 2002 _____./\/^>_*_<^\/\.______

Post a reply to this message

> > - removing an operator in release candidate (!) #6 (^)
>
> [...] Changing it would have resulted in the other
> group complaining.

Why? Who on earth would write -x^2 if they were expecting it to return the
same value as x^2? The correct behavior would have satisfied everybody, but
removing it satisfies nobody.

Anders

Post a reply to this message

"Thorsten Froehlich" <tho### [at] trfde> wrote in message
news:3d0af371@news.povray.org...
> In article <3d0ae109$1@news.povray.org> , "Karl J. Anders"
> <kar### [at] webde> wrote:
> > - removing an operator in release candidate (!) #6 (^)
>
> This has been removed to avoid getting complaints from people who don't
> understand that there can be more than one way how something works.  The
> feature used to work one way and thus we got complaints from those
favoring
> the other way of operation.  Changing it would have resulted in the other
> group complaining.  Others seemed to complain just for the sake of
> complaining and they didn't mind the original (MegaPOV) implementation not
> working different.  As the feature is redundant anyway and was only a 3.5
> beta addition and was not in 3.1 it has been removed because we don't want
> to have to waste our time with endless pointless discussions how it works
> and how some people expect it to work.

Too bad... I liked that nifty ^

I'd like to plead its case, but obviously there was already exentsive
discussion about it and I missed it... Could anybody kindly point me to that
discussion ? So that I might see if I have anything of value to add.
(Probably not.)

TIA

Povingly,

Philippe

Post a reply to this message

In article <3d0afa81@news.povray.org> , "Karl J. Anders" 
<kar### [at] webde> wrote:

>> There was no old behavior.
>
> Sorry, but that's wrong! 3.1g (mac) at least did return <0,0,0> and no error
> message - and this is, though mathematically definitely incorrect, quite
> useful in many cases. And some include files from other people, like
> TORSPLINE or CHEAP_SWEEP suddenly don't work as before :(
>
>> There never was a legal result being returned for a zero length vector and
>> the documentation clearly stated it.
>
> Sorry, but no, it didn't ! It does so with all 3.5 betas, but not with 3.1g.

It was pure luck that some versions of POV-Ray would return a valid result
in some cases.  In order to normalize the length one has to divide by the
length.  Consequently on systems were divisions by zero do not cause a fatal
exception some undefined garbage would have been returned.  That this
garbage would most of the time be zero on those platforms doesn't make it
the correct result...

Anyway, I am going to ignore any further messages posted to this thread in
order to end this discussion.

    Thorsten

____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povrayorg

I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Karl J. Anders <kar### [at] webde> wrote:
> - the often discussed problem about vnormalize( <0,0,0> ) = 0

  You complain that vnormalize(<0,0,0>) returns an error, yet you don't
complain that 1/0 returns an error.
  However, they are practically the same thing (the vnormalize also performs
a division by 0, as it divides each component with the length of the vector,
which is 0).

  1/0 is undefined. It has no value in the set of real numbers (or even the
set if imaginary numbers for that matter). Everyone accepts that.
  vnormalize(<0,0,0>) is undefined in the exact same way. There's no
unit-sized vector which would have the same direction as <0,0,0>, because
<0,0,0> has no direction nor length.

  If vnormalize(<0,0,0>) returns *any* value at all, that's just plain WRONG
(in the exact same way as 1/0 returning any value would be wrong). The value
it returns is *not* the correct answer. Thus, if it returns a value, it
would malfunction; it would work against its specification.
  If you try to normalize a zero vector, that's an error and the correct
behaviour for POV-Ray is to issue an error message, in the exact same way
as trying to divide by 0 is an error.

  Avoiding the error is as simple as avoiding division by 0.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

> Too bad... I liked that nifty ^
>
> I'd like to plead its case, but obviously there was already exentsive
> discussion about it and I missed it... Could anybody kindly point me to
that
> discussion ?

http://news.povray.org/3cf11123@news.povray.org

I think Thorsten's main argument was that changing it would supposedly make
expressions like x*-y illegal, even though I see no reason that should be
the case. After the parser sees 'x*', it should be expecting a new
expression, and when it sees the '-' it shouldn't care whether unary '-' has
lower precedence than '*', right?

Anders

Post a reply to this message

> It was pure luck that some versions of POV-Ray would return a valid result
> in some cases.

Looking at the 3.1 source, it sure doesn't look like luck to me! However, I
agree that vnormalize(0) shouldn't be defined. It's really a question of
whether you want to preserve this for backwards compatibility.

Anders

--
light_source{6#local D=#macro B(E)#macro A(D)#declare E=(E-#declare
C=mod(E D);C)/D;C#end#while(E)#if(A(8)=7)#declare D=D+2.8;#else#if(
C>2)}torus{1..2clipped_by{box{-2y}}rotate<1 0C>*90translate<D+1A(2)
*2+1#else}cylinder{0(C-v=1).2translate<D+C*A(2)A(4)#end-2 13>finish
{specular 1}pigment{rgb x}#end#end#end-8;1B(445000298)B(519053970)B
(483402386)B(1445571258)B(77778740)B(541684549)B(42677491)B(70)}

Post a reply to this message