Fortran syntax question (involving **) 
Author Message
 Fortran syntax question (involving **)

I have a question about fortran 95 syntax (though it likely applies
all the way back).

AFAICS the syntax rules for ** are

R701 :     primary      IS  constant
                        OR  constant-subobject
                        OR  variable
                        OR  array-constructor
                        OR  structure-constructor
                        OR  function-reference
                        OR  ( expr )

R703 :     level-1-expr IS [defined-unary-operator] primary

R705 :     mult-operand IS level1-expr [power-op mult-operand]

However that doesn't seem to allow expressions like

        2.0 ** -3
or
        x ** -i

since the only place a unary - can occur is inside the bracketed
expression recursion.

Such expression are, though, accepted by (at least the Intel) Fortran
compiler, and seem natural things to write.

What did I miss !?

--
-- Jim
--

Etnus, LLC.     +44 117 9071438
http://www.*-*-*.com/



Sat, 15 Dec 2007 21:08:17 GMT  
 Fortran syntax question (involving **)

Quote:

>However that doesn't seem to allow expressions like

>        2.0 ** -3
>or
>        x ** -i

>since the only place a unary - can occur is inside the bracketed
>expression recursion.

>Such expression are, though, accepted by (at least the Intel) Fortran
>compiler, and seem natural things to write.

>What did I miss !?

That this is an extension supported by the Intel compiler, and called out as
such in the Language Reference, which gives an example of where the behavior
can lead to unexpected results if you don't understand what is going on.  For
example:

        A ** -B * C

is evaluated as:

        A ** (-  (B * C))

and:

        X / -15.0 * Y

is evaluated as:

        X / (- (15.0 * Y))

Especially with constants, you have to be aware that the unary minus is an
operator with its usual precedence and is not "attached to" the constant.
There is no concept of a "negative number constant" in Fortran syntax.

Steve Lionel
Software Products Division
Intel Corporation
Nashua, NH

User communities for Intel Software Development Products
  http://softwareforums.intel.com/
Intel Fortran Support
  http://developer.intel.com/software/products/support/



Sat, 15 Dec 2007 21:52:39 GMT  
 Fortran syntax question (involving **)
In addition to Steve's comment, notice that this generates an error
with ifort if the '-e95' option is used:

vondele/g95> ifort -e95 mytest.f90
fortcom: Error: mytest.f90, line 1: Non-standard extension
write(6,*) 3**-2
--------------^
compilation aborted for mytest.f90 (code 1)

Cheers,

Joost



Sat, 15 Dec 2007 22:28:22 GMT  
 Fortran syntax question (involving **)

Quote:
> Especially with constants, you have to be aware that the unary minus is an
> operator with its usual precedence and is not "attached to" the constant.
> There is no concept of a "negative number constant" in Fortran syntax.

In the context of this remark, is this error message really correct ?

Quote:
>cat mytest.f90

   REAL, DIMENSION(-1:1) :: A
END

Quote:
>ifort -e95 mytest.f90

fortcom: Error: mytest.f90, line 1: Fortran 95 specifies that an
elemental intri nsic function here be of type integer or character and
each argument must be an initialization expr of type integer or
character .
   REAL, DIMENSION(-1:1) :: A
-------------------^
compilation aborted for mytest.f90 (code 1)

Thanks,

Joost



Sat, 15 Dec 2007 23:12:46 GMT  
 Fortran syntax question (involving **)

Quote:

> > Especially with constants, you have to be aware that the unary minus is an
> > operator with its usual precedence and is not "attached to" the constant.
> > There is no concept of a "negative number constant" in Fortran syntax.

> In the context of this remark, is this error message really correct ?
...
>    REAL, DIMENSION(-1:1) :: A
...
> fortcom: Error: mytest.f90, line 1: Fortran 95 specifies that an
> elemental intri nsic function here be of type integer or character and
> each argument must be an initialization expr of type integer or
> character .

The error message is incorrect, but I don't see what this has to do with
the context of the remark. The error message is incorrect because

1. There is no error at all. The code is perfectly standard-conforming
f90. Thus any error message would be incorrect. (A warning about the
unused variable might be in order... or for that matter a warning about
the entire program being a noop - though that's not a typical warning),
but any error (as opposed to warning) message is incorrect.

2. There are no intrinsic functions anywhere in sight, so a message
about intrinsic functions is incorrect.

The only connection I see between this code and the remark is the
observation that -1 is an initialization expression consisting of the
primary "1" and a unary operator "-". But I don't see what this has to
do with the error message.

I haven't verified the behavior, but it just looks like a plain old
unadorned compiler bug to me - no subtle matters of definition or
interpretation involved.

--
Richard Maine                       |  Good judgment comes from experience;
email: my first.last at org.domain  |  experience comes from bad judgment.
org: nasa, domain: gov              |        -- Mark Twain



Sat, 15 Dec 2007 23:32:19 GMT  
 Fortran syntax question (involving **)

Quote:
> The only connection I see between this code and the remark is the
> observation that -1 is an initialization expression consisting of the
> primary "1" and a unary operator "-". But I don't see what this has to
> do with the error message.

You're quite right ... the best I could come up with now is something
like: if a "negative number constant" existed, this compiler bug
wouldn't have occurred ?

;-)

Joost



Sat, 15 Dec 2007 23:54:25 GMT  
 Fortran syntax question (involving **)

Quote:
> Especially with constants, you have to be aware that the unary minus is an
> operator with its usual precedence and is not "attached to" the constant.
> There is no concept of a "negative number constant" in Fortran syntax.

This is a pet peeve of mine, and I have never seen a compiler
get it right.  Let's try an experiment:

program neg_const
   integer, parameter :: ik1 = selected_int_kind(2)
   integer, parameter :: ik2 = selected_int_kind(4)
   integer, parameter :: ik4 = selected_int_kind(9)
   integer, parameter :: ik8 = selected_int_kind(18)

   write(*,*) -128_ik1
   write(*,*) -128_ik1+1
   write(*,*) -128_ik1*1
   write(*,*) -128_ik1**1
   write(*,*) -32768_ik2
   write(*,*) -32768_ik2+1
   write(*,*) -32768_ik2*1
   write(*,*) -32768_ik2**1
   write(*,*) -2147483648_ik4
   write(*,*) -2147483648_ik4+1
   write(*,*) -2147483648_ik4*1
   write(*,*) -2147483648_ik4**1
   write(*,*) -9223372036854775808_ik8
   write(*,*) -9223372036854775808_ik8+1
   write(*,*) -9223372036854775808_ik8*1
   write(*,*) -9223372036854775808_ik8**1
end program neg_const

C:\LF9556\James\clf\neg_const>ifort /stand:f95 /c neg_const.f90
Intel(R) Fortran Compiler for 32-bit applications, Version 8.1    Build
20050201
Z Package ID: w_fc_pc_8.1.028
Copyright (C) 1985-2005 Intel Corporation.  All rights reserved.
30 DAY EVALUATION LICENSE

ifort: NOTE: The evaluation period for this product ends on 12-jul-2005 UTC.
neg_const.f90(9) : Warning: The BYTE / LOGICAL(KIND=1) / INTEGER(KIND=1)
value i
s out-of-range.   [128]
   write(*,*) -128_ik1*1
---------------^
neg_const.f90(10) : Warning: The BYTE / LOGICAL(KIND=1) / INTEGER(KIND=1)
value
is out-of-range.   [128]
   write(*,*) -128_ik1**1
---------------^
neg_const.f90(13) : Warning: The INTEGER(KIND=2) value is out-of-range.
[32768
]
   write(*,*) -32768_ik2*1
---------------^
neg_const.f90(14) : Warning: The INTEGER(KIND=2) value is out-of-range.
[32768
]
   write(*,*) -32768_ik2**1
---------------^
neg_const.f90(17) : Warning: The INTEGER(KIND=4) value is out-of-range.
[21474
83648]
   write(*,*) -2147483648_ik4*1
---------------^
neg_const.f90(18) : Warning: The INTEGER(KIND=4) value is out-of-range.
[21474
83648]
   write(*,*) -2147483648_ik4**1
---------------^
neg_const.f90(21) : Error: The decimal constant was too large when
converting to
 an integer, and overflow occurred.   [9223372036854775808]
   write(*,*) -9223372036854775808_ik8*1
---------------^
neg_const.f90(22) : Error: The decimal constant was too large when
converting to
 an integer, and overflow occurred.   [9223372036854775808]
   write(*,*) -9223372036854775808_ik8**1
---------------^
compilation aborted for neg_const.f90 (code 1)

I suppose congratulations are in order.

--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end



Sun, 16 Dec 2007 00:06:37 GMT  
 Fortran syntax question (involving **)

Quote:

> > The only connection I see between this code and the remark is the
> > observation that -1 is an initialization expression consisting of the
> > primary "1" and a unary operator "-". But I don't see what this has to
> > do with the error message.

> You're quite right ... the best I could come up with now is something
> like: if a "negative number constant" existed, this compiler bug
> wouldn't have occurred ?

Plausibly. Except...

I'd like to see negative number constants added to the standard. In 99%
of the cases, the question is moot. But the inability to write the
largest negative number of typical current representations in literal
form with obscure tricks is annoying. (One trick is to write something
like -127-1 instead of -128). The problem I see is that this would
require that the parsing rules get more complicated to avoid
ambiguities. Sometimes -1 would be a negative constant, while other
times it would be a unary operator and a positive constant; you'd have
to look at the rest of the context to know.

I'm reasonably confident that the special-case rules could be written
(and implemented). But this would make parsing more complicated rather
that less. I doubt it would be a major complication (I could be wrong on
that, but that's my guess), but it would at least be in the direction of
more complication rather than less. Thus, I'm not convinced that it
would result in fewer compiler bugs.

--
Richard Maine                       |  Good judgment comes from experience;
email: my first.last at org.domain  |  experience comes from bad judgment.
org: nasa, domain: gov              |        -- Mark Twain



Sun, 16 Dec 2007 00:33:13 GMT  
 Fortran syntax question (involving **)

(snip)

Quote:
> Especially with constants, you have to be aware that the unary minus is an
> operator with its usual precedence and is not "attached to" the constant.
> There is no concept of a "negative number constant" in Fortran syntax.

There is, but you have to be careful where you use it.

For the DATA statement some of the possibilities are
signed-int-literal-constant and signed-real-literal-constant.

But in most other places, there are no negative constants.

-- glen



Sun, 16 Dec 2007 01:33:41 GMT  
 Fortran syntax question (involving **)

Quote:
>n the context of this remark, is this error message really correct ?

>>cat mytest.f90
>   REAL, DIMENSION(-1:1) :: A
>END

>>ifort -e95 mytest.f90
>fortcom: Error: mytest.f90, line 1: Fortran 95 specifies that an
>elemental intri nsic function here be of type integer or character and
>each argument must be an initialization expr of type integer or
>character .
>   REAL, DIMENSION(-1:1) :: A
>-------------------^
>compilation aborted for mytest.f90 (code 1)

Amusing.  As Richard says, this has nothing to do with the topic in question,
but it is a bug nonetheless.   I'll report it.

Steve Lionel
Software Products Division
Intel Corporation
Nashua, NH

User communities for Intel Software Development Products
  http://softwareforums.intel.com/
Intel Fortran Support
  http://developer.intel.com/software/products/support/



Sun, 16 Dec 2007 01:36:46 GMT  
 Fortran syntax question (involving **)
On Tue, 28 Jun 2005 10:06:37 -0600, "James Van Buskirk"

Quote:

>I suppose congratulations are in order.

Thanks.  Our compiler correctly conforms to the standard in this regard.  Or
did you intend something else?

As Richard Maine correctly says, it is not possible in standard Fortran to
express as a literal constant the most negative value of an integer type/kind.
Yes, this is a major annoyance.

Note further that the "model for integer data" in the Fortran standard is
expressed as a sign times a value, so that it is symmetrical, even if the
underlying representation is asymmetrical.

Steve Lionel
Software Products Division
Intel Corporation
Nashua, NH

User communities for Intel Software Development Products
  http://softwareforums.intel.com/
Intel Fortran Support
  http://developer.intel.com/software/products/support/



Sun, 16 Dec 2007 01:33:30 GMT  
 Fortran syntax question (involving **)

(snip)

Quote:
> I'd like to see negative number constants added to the standard. In 99%
> of the cases, the question is moot. But the inability to write the
> largest negative number of typical current representations in literal
> form with obscure tricks is annoying. (One trick is to write something
> like -127-1 instead of -128). The problem I see is that this would
> require that the parsing rules get more complicated to avoid
> ambiguities. Sometimes -1 would be a negative constant, while other
> times it would be a unary operator and a positive constant; you'd have
> to look at the rest of the context to know.

Not to worry too much, C has the same problem.
I think I would rather have a special exception for integer constants
to allow the largest negative value.

I find the explanation of the intel compiler:
(cut and paste from another post)

 >   A ** -B * C

 > is evaluated as:

 >   A ** (-  (B * C))

 > and:

 >   X / -15.0 * Y

 > is evaluated as:

 >   X / (- (15.0 * Y))

very strange.

Quote:
> I'm reasonably confident that the special-case rules could be written
> (and implemented). But this would make parsing more complicated rather
> that less. I doubt it would be a major complication (I could be wrong on
> that, but that's my guess), but it would at least be in the direction of
> more complication rather than less. Thus, I'm not convinced that it
> would result in fewer compiler bugs.

-- glen


Sun, 16 Dec 2007 01:45:17 GMT  
 Fortran syntax question (involving **)
On Tue, 28 Jun 2005 13:36:46 -0400, Steve Lionel

Quote:

>>>ifort -e95 mytest.f90
>>fortcom: Error: mytest.f90, line 1: Fortran 95 specifies that an
>>elemental intri nsic function here be of type integer or character and
>>each argument must be an initialization expr of type integer or
>>character .
>>   REAL, DIMENSION(-1:1) :: A
>>-------------------^
>>compilation aborted for mytest.f90 (code 1)

>Amusing.  As Richard says, this has nothing to do with the topic in question,
>but it is a bug nonetheless.   I'll report it.

Just to clarify, the bug is that a standards warning (or error, since you
asked for standards warnings to become errors)  is generated.  Otherwise, it
works just fine.

Steve Lionel
Software Products Division
Intel Corporation
Nashua, NH

User communities for Intel Software Development Products
  http://softwareforums.intel.com/
Intel Fortran Support
  http://developer.intel.com/software/products/support/



Sun, 16 Dec 2007 02:00:07 GMT  
 Fortran syntax question (involving **)

Quote:


> (snip)

>> I'd like to see negative number constants added to the standard.
>> In 99% of the cases, the question is moot. But the inability to
>> write the largest negative number of typical current
>> representations in literal form with obscure tricks is annoying.
>> (One trick is to write something like -127-1 instead of -128). The
>> problem I see is that this would require that the parsing rules
>> get more complicated to avoid ambiguities. Sometimes -1 would be a
>> negative constant, while other times it would be a unary operator
>> and a positive constant; you'd have to look at the rest of the
>> context to know.

> Not to worry too much, C has the same problem.
> I think I would rather have a special exception for integer
> constants to allow the largest negative value.

So would I.  Havng a special case for the syntax of literals would
be a mess.

For the largest negative value I always write ishft(1,bit_size(0)-1).
This makes the purpose clear.  Sure, for 8-bit integers (assuming
your implementation supports them) it's easy to remember -128.
But, what about 32-bit integers or 64-bit integers?  I seldom
remember that the largest negative 32-bit value is 2147483648.
(That is, assuming it really *is* 2147483648 and I haven't made
some error.)  Now, in my own language, the type of the literals is
"infinite precision integers", so there is no difficulty in writing
-2147483648, other than its lack of clarity.

Note that this issue is not really directly relevant to the original
question of exponentiation.  I'd still rather see parenthesis required
even if the exponent's value is a literal.  Other languages solve this
by making unary signs have high precedence.  It's way too late for
that to be the Fortran solution.  However, any extended Fortran
that permitted a negative exponent without the parentheses should
treat X ** -Y * Z as X ** (-Y) * Z and not X ** (-Y * Z).  The latter
is almost certainly not the programmer's intent.

--
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies."   --  C. A. R. Hoare



Sun, 16 Dec 2007 04:35:26 GMT  
 Fortran syntax question (involving **)
(snip)

Quote:
> Note that this issue is not really directly relevant to the original
> question of exponentiation.  I'd still rather see parenthesis required
> even if the exponent's value is a literal.  Other languages solve this
> by making unary signs have high precedence.  It's way too late for
> that to be the Fortran solution.  However, any extended Fortran
> that permitted a negative exponent without the parentheses should
> treat X ** -Y * Z as X ** (-Y) * Z and not X ** (-Y * Z).  The latter
> is almost certainly not the programmer's intent.

C has some interesting precedence problems with the shift operators
that confuse new (and not so new) users, but it does have both unary and
binary + and - operators with appropriate precedence.

I do agree that exponentiation should follow the rules of algebra if one
wants it as an extension.

-- glen



Sun, 16 Dec 2007 06:00:40 GMT  
 
 [ 17 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Syntax Question involving parameters, function, ranges...

2. fortran syntax question

3. Fortran 77 syntax question

4. Syntax Questions for a new language with somewhat Smalltalk-like syntax

5. block syntax/def syntax question/suggestion

6. c-ffi question involving c-struct

7. Two questions (Sorry, Goobers no cash involved :-)

8. Conformance question involving equivalence

9. Intersesting Questions involving extending and embedding

10. Implementing letrec-syntax using only let-syntax and syntax-rules

11. Fortran syntax

12. paper comparing Fortran 90, C++, Matlab syntax

 

 
Powered by phpBB® Forum Software