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

Nathan Kopp <nat### [at] koppcom> wrote:
> There's a fundamental difference between vnormalize(<0,0,0>) and 1/0:
> backwards compatibility.  :-)

  I don't think vnormalize has ever been defined as returning <0,0,0> if
a zero-vector is given to it. What has not been defined can change in the
future without breaking backwards compatibility.
  Besides, backwards compatibility has never been such a strong issue in
POV-Ray to maintain bad behaviour or bad features. For example, filter
working as transmit in layered textures was a bad behaviour and it was
fixed regardless of breaking backwards compatibility.

  IMO trying to perform vnormalize(<0,0,0>) is a sign of a programming
mistake (ie. bug) and thus the error is only helpful. If the algorithm
is properly made, such case should never happen (in the exact same way as
dividing by 0 should never happen).

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

Jonathan Wooldridge wrote in message <3d0bb13f$1@news.povray.org>...
>Why would a feature be "de-implemented"? What advantage is it to the coding
>team to eliminate the feature?

Reducing tech-support headaches.  By eliminating the ^ operator, the
POV-Team will get far fewer e-mails complaining about operator precedence
being broken with respect to the ^ operator.


--
Mark

The Universe is expanding.
The budget for its exploration is shrinking.

Post a reply to this message

Im Beitrag <3d0b6c80@news.povray.org>, Warp <war### [at] tagpovrayorg> schrieb:
>   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).
>
Sorry, but that is not absolutely true, because that is NOT taking 1/0, but
0/0, and that can, depending on the circumstances, be almost anything.

And I KNOW (!) that it is rightfully undefined.

As I pointed out earlier in this thread, a function that returns the
normalized vector IF POSSIBLE and <0,0,0> else is USEFUL - and at least on
my system, POV3.1g and MacMegaPOV0.7 DID behave like that - and since it is
USEFUL, there were already people writing macros "Vnormalize" (or
"VNormalize") that work like that (sorry, I can't find the threads in a
hurry, but they WERE here !).

The serious (i.e. not bracketed and smiley-free) part of my proposal was to
add such a macro to an appropriate include file, so that this functionality
can used by all with the same macro name, if they wish to.

Again: I KNOW that the "new" - or not so new - behaviour is mathematically
correct, that is NOT my point !

Karl

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

Post a reply to this message

Karl J. Anders <kar### [at] webde> wrote:
> Sorry, but that is not absolutely true, because that is NOT taking 1/0, but
> 0/0, and that can, depending on the circumstances, be almost anything.

  Actually it's nothing. It's not defined in any system.
  Even FPU's, when you actually perform 0/0 (and they are set up so that
they will not execute an interrupt if such thing happens) will return NaN
(Not a Number), which is a special value which is not usable anywhere.

> The serious (i.e. not bracketed and smiley-free) part of my proposal was to
> add such a macro to an appropriate include file, so that this functionality
> can used by all with the same macro name, if they wish to.

  Such macro is so extremely simple that I don't see any good reason for
including it in the standard include files.
  In the same way we should also include a macro which returns 0 if something
is divided by 0. It just doesn't make sense.

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