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

Post a reply to this message

"Greg M. Johnson" <gregj:-)565### [at] aolcom> wrote in message
news:3dd42187$3@news.povray.org...
> "AC" <amb### [at] teliacom> wrote in message news:3dd3e7b2@news.povray.org...
> >
> > My vote would be on -3^2=9
> >
>
>
> The problem is that you're more likely to have   4^2-3^2.
>
>
>
>
good point... looking at it this way  think I will have to change my mind...
Ambis

Post a reply to this message

Christopher James Huff wrote:
>In article <3dd3cb3c$1[at]news.povray.org>, "Slime" <slm### [at] slimelandcom>
>wrote:
>
>> Well, to say there's no mathematical reason doesn't seem entirely correct.
>> Most everyone is taught that exponentiation comes before negation in an
>> early algebra class. It's the way we've been taught to think.
>
>Um, no. In algebra, there is no precedence, the exponent is in
>superscript, so there is no ambiguity. A plain text programming language
>doesn't have this, an operator has to be used, so it has to pick a
>precedence. I don't know what you were taught...

I'm not sure I understand.  If I read - 2 sup 3, I would interpret it as -(2
sup 3) = -8, just like 4 - x^3 would mean "four minus the cube of x" and
not "four plus the cube of minus x".  And I am not symbolic expert but I've
done my fair share of heavy lifting in mathematics.  I'm pretty sure many,
if not most, people would read it the same way.

On the other hand, if the issue is the parsing of 2^-3, I can see a problem.
 Since in algebra it's a real superscript, it's clear this would be "two to
the power of minus 3", but to a computer parsing plaintext, it's awkward.
Does - bind more tightly than ^?  I can see the issue.  But I'm not sure I
agree with the "solution".

The simplest way out would seem, to my eye, to disallow 2^-3 -- make it a
syntax error for ^ to be followed by anything but a number, an identifier,
or a parenthesis.  It would be annoying, when one used "2^-3" to have to
check the documentation and to have to learn a "different" way of seeing
things.  But that's much preferable to stripping out a useful operator and
cluttering up lines and lines of scene code.  If it's a little harder for
the computer, or a little harder for humans, shouldn't the humans win?

>
>
>> 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.
>
>Christopher James Huff <cja### [at] earthlinknet>
>http://home.earthlink.net/~cjameshuff/
>POV-Ray TAG: chr### [at] tagpovrayorg
>http://tag.povray.org/
>

Post a reply to this message

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