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

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

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

And before somebody manages to interpret this the wrong way:

Every statement made by others about either of those working correctly or
changeable to work correctly are wrong!

I am not going to explain this further as it just wastes my time to teach
others programming to demonstrate I am correct.  If someone doesn't
understand it from either my already given explanation or the available
POV-Ray source code, it doesn't mean that person is correct and nobody
should jump to the conclusion that the current behavior of POV-Ray 3.5 is
incorrect in any way based on such a statement.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> wrote in message
news:3d0b6c80@news.povray.org...
> Karl J. Anders <kar### [at] webde> wrote:
> > - the often discussed problem about vnormalize( <0,0,0> ) = 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.

I would like to point out something not usually thought of: What is 1/0? I
notice that as the denominator approaches zero, the result approaches
infinity. 1 dividen into millionths results in a million pieces. 1 divided
into bajillionths results in a bajillion pieces.

Just because our digital mathematics aren't up to the task doesn't mean the
result doesn't exist. The result of dividing 1 by 0 should be infinity.

So it is an implementation problem that steps a little outside the
"standard" programmer's box. To solve this, you would have to create a
symbol to represent infinity, perhaps a keyword. Then you would have to
create a set of mathematical rules for the use of infinity:
x + infinity = infinity
x * infinity = infinity
infinity * infinity = infinity2 (there are many densities of infinity)

As you can see, my humble naming convention fails the task already. Any
better ideas?

Post a reply to this message

Jonathan Wooldridge <jwo### [at] attbicom> wrote:
> Just because our digital mathematics aren't up to the task doesn't mean the
> result doesn't exist. The result of dividing 1 by 0 should be infinity.

  Infinity does not belong to the set of real numbers, which is the set
which is used in practice.

  Besides, the problem with vnormalize(<0,0,0>) is that it would make
<0/0, 0/0, 0/0> and 0/0 is truely undefined (it's not infinity even if
we include infinity in our numerical system).

  There's no point in adding support for infinity because infinity is not
usable for anything (every operation which you can make with infinity results
in infinity, -infinity or undefined, none of which are usable in practice).

-- 
#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

"Thorsten Froehlich" <tho### [at] trfde> wrote in message
news:3d0b8956@news.povray.org...
> In article <3d0b536d$1@news.povray.org> , "Thorsten Froehlich"
> <tho### [at] trfde> wrote:
>
> And before somebody manages to interpret this the wrong way:
>
> Every statement made by others about either of those working correctly or
> changeable to work correctly are wrong!
> I am not going to explain this further as it just wastes my time to teach
> others programming to demonstrate I am correct.  If someone doesn't
> understand it from either my already given explanation or the available
> POV-Ray source code, it doesn't mean that person is correct and nobody
> should jump to the conclusion that the current behavior of POV-Ray 3.5 is
> incorrect in any way based on such a statement.
>
>     Thorsten

It has been my experience that when a discussion heads south, like this one
has, it is usually because the actual cause of the problem isn't being
covered.

It seems more likely to me that the implementation was difficult, and
therefore aborted. Or perhaps it was a political decision, where someone in
charge decided that a feature "isn't necessary", and never mind the people
who are using the program. Maybe someone who was working on it got demoted
or kicked off the project. Maybe a new person was handed the task, and
doesn't know how to fix it yet. Who knows, really?

Why would a feature be "de-implemented"? What advantage is it to the coding
team to eliminate the feature?

Post a reply to this message

"Anders K." <and### [at] prostard2gcom> wrote in message
news:3d0b768f@news.povray.org...
> > 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

Thnaks

> 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?

Er... I am no programmer, neither mathematician... Seeing the heated debate
that took place, I do not really want to step into this discussion, or to
reopen it. As a user, both solutions do seem acceptable. It is true that
pow(float,float) does prevent this 'ambiguity'.



I remember some other intense arguments about some other features or bugs
(depending on the opinion one held) (e.g. : normal scaling ; media scaling)
and I trust the Pov-team to adopt a, or the, good solution. However, the
entire removal of the hat operator, rather than the implementation or the
continuation of the standard behaviour (searching for that I realised that

irritation than by reason... Yet, I understand after such a long and intense
underground work.



On a lighter note, I am looking forward to the re-emergence of this
discussion for the various hat-patches that are bound to appear when the 3.5
source code is released ;-)



Keep up this excellent work !





Povingly,





Philippe

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> wrote...
>   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).

There's a fundamental difference between vnormalize(<0,0,0>) and 1/0:
backwards compatibility.  :-)  That is the crux of this issue, in my
opinion.  If we were writing a new raytracer or even writing a new scene
description language (SDL), sticking to the strict, pure rules of math would
be perfectly legitimate, and probably desired.  But we are neither writing a
new raytracer nor creating a new SDL.

-Nathan

Post a reply to this message