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