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