TinCanMan <Tin### [at] hotmailcom> wrote:
> don't forget brackets supercede everything: hence 'BEDMAS'

> Brackets
> Exponents
> Divison*
> Multiplication*
> Addition**
> Subtraction**

> D&M,A&S are interchangeable of course, they are just in that order fo the
> mnemonic.

  Actually that list should be written so that it's clear that eg.
addition and substraction have the same precedence. Having the same
precendence is completely different from being contiguous in the precedence
list, but one having higher precedence than the other.
  The general rule is that when there is more than one operator with the
same precedence, they are evaluated from left to right. Operators with
different precedences are evaluated in decreasing order of precedence.
  This means that "2-3+4" evaluates to a different value depending on this
difference.

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

"Tor Olav Kristensen" <tor### [at] hotmailcom> wrote in message
news:web.3dd4440dc24ffac838149fba0@news.povray.org...
> Christopher James Huff wrote:
> >In article <3dd3cb3c$1[at]news.povray.org>, "Slime"
<slm### [at] slimelandcom>
> >wrote:
> .....
> >> Besides, I would think that since we're adding ^ as a new operator, we
could
> >> give it whatever precedence we wanted, and it just seems more logical
to me
> >> to make it work the way we've been taught it should work than to allow
the
> >> 2^-3 syntax just for convenience.
> >
> >Not for convenience, for self consistency. There isn't an existing rule,
> >so the one that was most logical and consistent was chosen.
>
> How about just requiring that the hat
> operator should always be preceeded
> by a pair of parantesis.
>
> Like this:   ( )^
>
> E.g.:   (3)^-3 or (-4)^2
>
>
> Tor Olav
>
>
That would be a possible solution that would work... for me, But it would be
a problem for those who don't know about it.

Post a reply to this message

"Alan Kong" <ako### [at] povrayWWWSPAMCOMorg> wrote in message
news:hr78tu0f6n273u6b5hrb8prkdr58iijtga@4ax.com...
> On Thu, 14 Nov 2002 16:54:54 -0500 "Greg M. Johnson"
> <gregj:-)565### [at] aolcom> wrote:
>
> >How is this off-topic?
>
>   Greg, it's off-topic when people argue a point for the argument's
> sake. It's not a real discussion, as the same points are brought up
> again and again.


No, you've made a value judgement and incorrect prediction of the discussion
that's about to occur.  There's the new point this time about folks
accepting a warning.

Post a reply to this message

On Thu, 14 Nov 2002 17:18:08 -0500, Greg M. Johnson wrote:
> The problem is that you're more likely to have   4^2-3^2.

That's not unary minus, and is thus exempt from the discussion.

However, unless I'm mistaken about my history, there was another problem 
with the exponentiation operator that was far more "interesting" from 
the coding perspective: exponentiation, by convention, associates right-
to-left, while all other binary operators associate left-to-right.  Thus, 
2^2^3 is 2^8, or 256, rather than 4^3 (64).  Not having an exponentiation 
operator means having a much simpler parser and/or compiler.

Besides, C doesn't have an exponentiation operator, and that's never 
really been a problem.  I mean, why don't we have a "length" operator, 
since it's so much easier to write |A| than vlength(A)?  Why don't we 
have an "angle" operator of some kind, since it's so much easier to 
write a#b or A#B than atan2(a,b) or atan2(vlength(vcross(A,B)),vdot(A,B))
(that's the angle between two vectors A and B.)  For that matter, why 
don't we have C's modulo operator?  What is it about the exponentiation
operator that gets everyone up in arms?

Okay, okay, so it's Pythagoras.  Or, as I like to say, vlength(<a,b,c>),
which is actually shorter than sqrt(a^2+b^2+c^2), and far more likely to
be meaningful to the math-disinclined.  (The 2d version is actually a 
character longer, but nobody uses 2d anymore, right?)

-- 
#local R=<7084844682857967,0787982,826975826580>;#macro L(P)concat(#while(P)chr(
mod(P,100)),#local P=P/100;#end"")#end background{rgb 1}text{ttf L(R.x)L(R.y)0,0
translate<-.8,0,-1>}text{ttf L(R.x)L(R.z)0,0translate<-1.6,-.75,-1>}sphere{z/9e3
4/26/2001finish{reflection 1}}//ron.parker@povray.org My opinions, nobody else's

Post a reply to this message

On 15 Nov 2002 09:01:39 -0500, Ron Parker <ron### [at] povrayorg> wrote:
> vlength(<a,b,c>),
> which is actually shorter than sqrt(a^2+b^2+c^2)

... but longer than f_r(a,b,c) :-)

ABX

Post a reply to this message

> > Brackets
> > Exponents
> > Divison*
> > Multiplication*
> > Addition**
> > Subtraction**
>
>
>   Actually that list should be written so that it's clear that eg.
> addition and substraction have the same precedence. Having the same
> precendence is completely different from being contiguous in the
precedence
> list, but one having higher precedence than the other.
>   The general rule is that when there is more than one operator with the
> same precedence, they are evaluated from left to right. Operators with
> different precedences are evaluated in decreasing order of precedence.
>   This means that "2-3+4" evaluates to a different value depending on this
> difference.
>

Sorry, it's just the mnemonic for OoO that (almost) everyone learns in grade
school.  Not really meant for higher thinking.

-tgq

Post a reply to this message

Warp wrote:
>   What you would have wanted is to make the unary minus to have a lower
> precedence. This would make "2^-3" illegal because a higher-precedence
> operator needs to be evaluated before the lower-precedence one and in
> this case it can't be done.

Ya know, this has been said before and I still don't see where it comes 
from.

In the case of a^-b, there is no choice as to what order the operation 
can be performed in, so precedence doesn't even come up.  Precedence 
isn't some rule that tells you what you can do, it just tells you which 
operation to perform first when you have a choice.

If you look in the manual for Bison, for example, operator precedence is 
a solution to an ambiguity.  When there's no ambiguity, the parser 
doesn't have to resort to checking precedence.  I understand POV's 
parser is probably different, but at least in an academic sense, the 
relative precedence of ^ and unary minus have no effect on a^-b.

-josh

Post a reply to this message