# Re: -1 ** 0 == -1 ???

#### Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

•  Subject
• Author
• Posted on
OK, egg on my face.  I see.

Sorry,

G.

--
NOTE: In my address everything before the first period is backwards;
and the last period, and everything after it, should be discarded.

## Re: -1 ** 0 == -1 ???

If you see, it's best to explain it so that other people can see.

I did a "man perlop", and the table is

Perl operators have the following associativity and precedence,
listed from highest precedence to lowest.  Operators borrowed
from C keep the same precedence relationship with each other,
even where C's precedence is slightly screwy.  (This makes
learning Perl easier for C folks.)  With very few exceptions,
these all operate on scalar values only, not array values.

left        terms and list operators (leftward)
left        ->
nonassoc    ++ --
right       **
right       ! ~ \ and unary + and -
left        =~ !~
left        * / % x
left        + - .
left        << >>
nonassoc    named unary operators
nonassoc    < > <= >= lt gt le ge
nonassoc    == != <=> eq ne cmp
left        &
left        | ^
left        &&
left        ||
nonassoc    ..  ...
right       ?:
right       = += -= *= etc.
left        , =>
nonassoc    list operators (rightward)
right       not
left        and
left        or xor

So what I think you see is that unary "-" has lower precedence than
"**", so
-1 ** 0
is equivalent to
-(1 ** 0)
Right?

--
Tim McDaniel, tmcd@panix.com

## Re: -1 ** 0 == -1 ???

kj wrote:

When startled, I try *not* to jump to the conclusion that whatever
language I am using is wholly unsuitable for any programming that
involves numerical computation.

I have done this for so long that it no longer requires much effort on
my part.

I assume that any programming language older than a few months with
widespread usage is suitable for numeric computation and that any odd
effects I am seeing are due to my own ignorance, stupidity or
foolishness - this has proved to be a good initial assumption. I commend
it to you :-)

--
RGB

## Re: -1 ** 0 == -1 ???

Um, you might be over-optimistic.

There's the famous feature of PL/I where 25 + 1/3 either throws a
fixed-point overflow error or evaluates to 5.33333...  I've seen both
statements and I have no way to test it;
<http://publib.boulder.ibm.com/infocenter/comphelp/v7v91/topic/com.ibm.aix.pli.doc/ibml2d41004828.htm
says it's an error but also mentions left-truncation.

The dc program was designed to do nothing but be a Reverse Polish
Notation calculator, but by default it does only pure integer
calculation (you can enter numbers with a decimal point: the
fractional part will be discarded silently).  You can change that, but
it provides only a fixed number of decimal places.

For that matter, it surprises new programmers when they learn that 1/3
equals 0, or that 1.0/3.0*3.0 does not necessarily equal 1.0, in many
languages.

(I have a dim memory that older Visual Basics were loosey-goosey about
mixing booleans and integers, and that the "not" operator is a bitwise
"not" instead of a logical one, and FALSE is 0, and integers are
ones-complement, so for all integers I except -1, both I and NOT I
were considered true.  But I'm not at all 100% certain of that, and
that's not really numeric.)

But that's really quibbling.  Your general point is quite true.
It's really REALLY rare for someone to find a new fundamental flaw in
a long-standing language.  By far the highest chance is that they're
misunderstanding something.  There's a much smaller chance that
they've hit a known long-standing problem.

--
Tim McDaniel, tmcd@panix.com