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

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
ISO wasn't free... I guess I still am naïve) looks more inspired by
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

Warp wrote:
>   Such macro is so extremely simple that I don't see
> any good reason for including it in the standard
> include files.

I'm not for or against such a macro, but I do know that there are some
of the macros in the standard include files that are way simpler and IMO
ridiculous than this proposed one.

Two examples from math.inc:

// Squares the components of a vector
#macro VSqr(V) (V*V) #end

// Distance between V1 and V2
#macro VDist(V1, V2) vlength(V1 - V2) #end

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:  http://rsj.mobilixnet.dk (updated May 20)
POV-Ray Users: http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Ring:  http://webring.povray.co.uk

Post a reply to this message

Rune <run### [at] mobilixnetdk> wrote:
> I'm not for or against such a macro, but I do know that there are some
> of the macros in the standard include files that are way simpler and IMO
> ridiculous than this proposed one.

  But at least they are consistent, logical and mathematically correct.

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

Warp wrote:
> But at least they are consistent, logical
> and mathematically correct.

This was not the issue in question. You was talking about the simplicity
of the macro. The issue of the mathematical correctness has already been
discussed, where Karl pointed out that it would be useful nonetheless.
That was the point where you swithed the subject to the issue of the
simplicity, which I responded to in my last post. Now you switched the
subject back again, and we could go on like this forever.

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:  http://rsj.mobilixnet.dk (updated May 20)
POV-Ray Users: http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Ring:  http://webring.povray.co.uk

Post a reply to this message

Rune <run### [at] mobilixnetdk> wrote:
> This was not the issue in question. You was talking about the simplicity
> of the macro. The issue of the mathematical correctness has already been
> discussed, where Karl pointed out that it would be useful nonetheless.
> That was the point where you swithed the subject to the issue of the
> simplicity, which I responded to in my last post. Now you switched the
> subject back again, and we could go on like this forever.

  I didn't change the subject (isn't "you switched the subject" a rather
cheap attack?).
  My point was that if he wants a function which does not work as its
mathematical specification says, he can easily do a macro implementing
such function himself. It makes no sense to include such macro in the
official distribution (in the exact same way as it makes no sense including
a macro which performs a division so that if something is divided by 0 it
will return 0, which is almost an identical case).
  A macro which squares a number might not be too useful, but at least it's
mathematically correct, which justifies better its inclusion. It doesn't
have any "if you give illegal parameters it will return a mathematically
incorrect result" exception.

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

Warp wrote:
>   I didn't change the subject (isn't "you switched
> the subject" a rather cheap attack?).

Yes, perhaps... :/

> My point was that if he wants a function which
> does not work as its mathematical specification
> says, he can easily do a macro implementing
> such function himself.

Many macros in the include files have no mathematical specifications at
all, they're just included because they're useful. Since we know that
there are many people who would also find the macro in question useful,
I don't see how it's any different from the others. There can be more
than one reason to include a macro, mathematical correctness being one,
and usefulness being another. The include files have 'em both.

Now, the macro in question is rather short and would be easy to make for
the user himself, but that also applies to macros that are already in
the include files. When deciding whether or not a short macro should be
included, I don't see why it makes any difference if the criteria for
inclusion is mathematical correctness or if it is usefulness. In both
cases the macro is valuable (an argument for inclusion), but also very
easy to create (an argument against inclusion).

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:  http://rsj.mobilixnet.dk (updated May 20)
POV-Ray Users: http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Ring:  http://webring.povray.co.uk

Post a reply to this message

Rune wrote:
> 
> Many macros in the include files have no mathematical specifications at
> all, they're just included because they're useful. Since we know that
> there are many people who would also find the macro in question useful,
> I don't see how it's any different from the others. There can be more
> than one reason to include a macro, mathematical correctness being one,
> and usefulness being another. The include files have 'em both.
>
> Now, the macro in question is rather short and would be easy to make for
> the user himself, but that also applies to macros that are already in
> the include files. When deciding whether or not a short macro should be
> included, I don't see why it makes any difference if the criteria for
> inclusion is mathematical correctness or if it is usefulness. In both
> cases the macro is valuable (an argument for inclusion), but also very
> easy to create (an argument against inclusion).
>
> Rune
> --

Thank you for precise expression of my thoughts - with one additional
sidestep ;) : since simpleness obviously is NOT a valid criterion for
exclusion ( didn't you mention VDist before ?), the reason for INclusion
probably is, that since many people can (and WILL) write such a macro, it's
helpful to provide it, so that there's just one name for that functionality
floating around, which simplifies exchange of scene files - and that's all I
wanted to express.

I REALLY whished some people would READ the posts they are answering ( now,
this one is NOT for you, Rune ), cause I already stated that I have already
written such a macro for myself, and yes, it is short, and yes, it is
simple, really don't need help with that :)

All in all, vnormalize is as redundant as the "^"-operator, because even the
docs describe its definition in terms of other POV-functions, so for
consistency it should be removed too ... ;)

( now, DID you all see that smiley ???!!!^)

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:
> Thank you for precise expression of my thoughts - with one additional
> sidestep ;) : since simpleness obviously is NOT a valid criterion for
> exclusion ( didn't you mention VDist before ?), the reason for INclusion
> probably is, that since many people can (and WILL) write such a macro, it's
> helpful to provide it, so that there's just one name for that functionality
> floating around, which simplifies exchange of scene files - and that's all I
> wanted to express.

  You know... Due to the way the parser is currently implemented, a macro
in an include file separate from the main .pov-file is slower to parse than
if the macro was located in the main file. Thus if you call the macro a lot
of times and you write the macro in your main .pov-file, it will parse
faster. :P

> All in all, vnormalize is as redundant as the "^"-operator, because even the
> docs describe its definition in terms of other POV-functions, so for
> consistency it should be removed too ... ;)

  At least it's a lot faster as a builtin function, if nothing else...

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

I very much prefer the hat notation too. Also I was 
playing with isosurfaces today and in 6.5.4.2 was the
simple exapmple:

isosurface{
 function{ x^2+y^2+z^2}
}

which we apparently now have to encode as 

 function{ pow(x,2)+pow(y,2)+pow(z,2) }

see why I prefer the hat?
If the only reason to eliminate the hat is that 
there is some confusion on the precedence, please
put it back and make sure the documentation is
correct. Also Thorsten, when making such big changes
on the syntax, communicate it to the guys who do the
doc. Now you have broken a number of examples from
the documentation.

As a further note, precedence is always a difficult 
thing. There are even variations between countries.
In Holland the precedence rules are that the order
for binary operators is: ^ * / + - 
and none has the same precedence. So 2*4/2 is 4 not 1
When something unexpected happens I always check
precedence and use superfluous parenthesis, just to be
sure :)

I still think POV is one of the best programs I ever
used, so keep up the good work.

	Andrel
 

Philippe Debar wrote:
> 
> "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

On Mon, 24 Jun 2002 14:01:38 -0500, andrel linnenbank wrote:

> I very much prefer the hat notation too. Also I was playing with
> isosurfaces today and in 6.5.4.2 was the simple exapmple:
> 
> isosurface{
>  function{ x^2+y^2+z^2}
> }
> 
> which we apparently now have to encode as
> 
>  function{ pow(x,2)+pow(y,2)+pow(z,2) }

function {x*x + y*y + z*z}
works fine and isn't any longer (except for whitespace). I do prefer the
hat notation though...I would have preferred it if the complaints about
precedence had just been ignored.


> As a further note, precedence is always a difficult thing. There are
> even variations between countries. In Holland the precedence rules are
> that the order for binary operators is: ^ * / + - and none has the same
> precedence. So 2*4/2 is 4 not 1 When something unexpected happens I
> always check precedence and use superfluous parenthesis, just to be sure

How could that equal 1? I don't see any precedence rule that could produce
that result...it either comes out to 8/2 or 2*2. Or +-: 2 + 3 - 5 = 0
whether you do the addition or subtraction first.


-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: <chr### [at] tagpovrayorg>
WWW: http://homepage.mac.com/chrishuff/

Post a reply to this message

> > As a further note, precedence is always a difficult thing. There are
> > even variations between countries. In Holland the precedence rules are
> > that the order for binary operators is: ^ * / + - and none has the same
> > precedence. So 2*4/2 is 4 not 1 When something unexpected happens I
> > always check precedence and use superfluous parenthesis, just to be sure
> 
> How could that equal 1? I don't see any precedence rule that could produce
> that result...it either comes out to 8/2 or 2*2. Or +-: 2 + 3 - 5 = 0
> whether you do the addition or subtraction first.
Whoops sorry, a more correct expample would be 
2*2/2*2 
which is 1 in Holland. it parses as (2*2)/(2*2) and 4 in some other
countries where they parse it as ((2*2)/2)*2 
 
Thank for pointing out, now I feel realy silly :)

	Andrel

Post a reply to this message

andrel linnenbank <a.c### [at] amcuvanl> wrote:
> Whoops sorry, a more correct expample would be 
> 2*2/2*2 
> which is 1 in Holland.

  Then you should not use programming languages like C, C++ or Java... ;)

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

Warp wrote:
> 
> andrel linnenbank <a.c### [at] amcuvanl> wrote:
> > Whoops sorry, a more correct expample would be
> > 2*2/2*2
> > which is 1 in Holland.
> 
>   Then you should not use programming languages like C, C++ or Java... ;)
What about POV?
In fact it is very simple: if you write a half as 0.5 then use one set
of precedence rules and if you write 0,5 use the dutch rules :)
(well at least that mostly works while staying in Holland)

	Andrel	

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

"andrel linnenbank" <a.c### [at] amcuvanl> wrote in message
news:3D1767A2.B71AB835@amc.uva.nl...
>
> > > As a further note, precedence is always a difficult thing. There are
> > > even variations between countries. In Holland the precedence rules are
> > > that the order for binary operators is: ^ * / + - and none has the
same
> > > precedence. So 2*4/2 is 4 not 1 When something unexpected happens I
> > > always check precedence and use superfluous parenthesis, just to be
sure
> >
> > How could that equal 1? I don't see any precedence rule that could
produce
> > that result...it either comes out to 8/2 or 2*2. Or +-: 2 + 3 - 5 = 0
> > whether you do the addition or subtraction first.
> Whoops sorry, a more correct expample would be
> 2*2/2*2
> which is 1 in Holland. it parses as (2*2)/(2*2) and 4 in some other
> countries where they parse it as ((2*2)/2)*2
>
> Thank for pointing out, now I feel realy silly :)
>
> Andrel

Hello,

I'm sorry, but I don't agree with Andrel. I'm a Dutch teacher and I have
never heard
about this kind of precedence. The '*' and  the '/' have equal precedence,
so
they parse in the order of appearance. The same rules applies to '+' and
'-'.
If he had learned it this way, then that was wrong. Mathematics have the
same rules
all over the world!!

Greetings,

--
Jaap Frank

Post a reply to this message

andrel linnenbank wrote in message <3D1767A2.B71AB835@amc.uva.nl>...
>
>> > As a further note, precedence is always a difficult thing. There are
>> > even variations between countries. In Holland the precedence rules are
>> > that the order for binary operators is: ^ * / + - and none has the same
>> > precedence. So 2*4/2 is 4 not 1 When something unexpected happens I
>> > always check precedence and use superfluous parenthesis, just to be
sure
>>
>> How could that equal 1? I don't see any precedence rule that could
produce
>> that result...it either comes out to 8/2 or 2*2. Or +-: 2 + 3 - 5 = 0
>> whether you do the addition or subtraction first.
>Whoops sorry, a more correct expample would be
>2*2/2*2
>which is 1 in Holland. it parses as (2*2)/(2*2) and 4 in some other
>countries where they parse it as ((2*2)/2)*2


This is what I like about postfix notation: 2 2 * 2 / 2 * is unambiguously
4.

--
Mark

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

Post a reply to this message

On Tue, 25 Jun 2002 02:18:15 -0500, Mark Wagner wrote:

> This is what I like about postfix notation: 2 2 * 2 / 2 * is
> unambiguously 4.

Have fun convincing anyone to use that... ;-)

Really, it seems like a tree would be a better representation than any
linear string:

      4
      =
      *
    /   2
  *   2
2   2

However, that makes it a bit difficult to write and takes up a lot of
room, and doesn't really work well anyway with plain text, maybe we can
use some kind of notation to let it all fit on a line and be easy to
type...I know, lets use () marks to enclose each branch: (((2*2)/2)*2)

Typing all those () is a pain though, maybe make some simple rules for
which operations to do first, people can still use () to force a different
order or clarify the meaning when needed. ;-)


-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: <chr### [at] tagpovrayorg>
WWW: http://homepage.mac.com/chrishuff/

Post a reply to this message

> Typing all those () is a pain though, maybe make some simple rules for
> which operations to do first, people can still use () to force a different
> order or clarify the meaning when needed. ;-)

In spite of this thread going on too long I have to add my 2 pennies.  I
have kikved by BEDMAS since grade school and whenever I am in doubt on how
the equation will be interpreted, I add brackets.

Post a reply to this message