- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I feel fun. that Intel fortran can use ++ or -- in the expression, which GNU fortran make the syntax errors.
It might be useful, however, this makes typing mistakes to pass OK.
print*, 2.0
print*,-2.0
print*, --2.0 ! number 2 with two minus signs is the number 2 back.
print*,---2.0 ! number 2 with three minus signs is the minus 2.
print*,+3.0
print*,++3.0 ! number 3 with two plus sign is the number 3.
print*, +++3.0
print*, -4.0 ! gives -4.0 as usual.
print*,+-4.0 ! gives -4.0
print*,-+-4.0 ! gives 4.0
print*, 1.0--2.0 !gives 3.0
print*, 1.0---3.0 ! gives -2.0.
print*, x--y, x++y, x+-y, x-+y, x---y, x--+y ! etc.
Hiroshi Murakami
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
If you set -stand, I suppose ifort should report error.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The Fortran standard does not explicitly disallow or allow stacking unary operators. We chose to allow it.
Annalee
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
1E--3, 1E++5
In the program are syntax errors.
When a data is read, --3.0 or ++3.0 causes errors since these are just signs and are not operators.
And another interesting thing is, IEEE 754 floating point number system has signs for zeros, the positive zero and negative zero.
write(*,'(Z,3X,Z)') +0.0,-0.0
will reveal different binary representations are used for 0.0 and -0.0.
And, 1.0/(+0.0),1.0/(-0.0) gives Infinity and -Infinity correctly.
But, (0.0)==(-0.0) gives True!
Thus we need not write abs(x)==0.0 to test if x is zero (positive zero or negative zero)
but write just x==0.0
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
negative 0 is an interesting beast
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Annalee (Intel) wrote:
The Fortran standard does not explicitly disallow or allow stacking unary operators. We chose to allow it.
Annalee
There are some situations where naked unary operators show up in applications where it's not permitted by standard and is not always reasonably interpreted by compilers which accept it e.g. A ** - B
Metcalf, Reid, Cohen have some discussion about this but don't appear to have a firm conclusion on the point Annalee just made.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
read(*,*)x ! this is very standard.
write(*,*)x ! this is very standard.
read(*,*),x ! ifort accepts this.
write(*,*),x ! ifort accepts this.
read(*,*), ! ifort accepts this also.
write(*,*), ! ifort accepts this also.
read*,,x ! ifort does not accept this.
print*,,x ! ifort does not accept this.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
hiroshi-murakami wrote:
And another interesting thing is, IEEE 754 floating point number system has signs for zeros, the positive zero and negative zero.
write(*,'(Z,3X,Z)') +0.0,-0.0
will reveal different binary representations are used for 0.0 and -0.0.
And, 1.0/(+0.0),1.0/(-0.0) gives Infinity and -Infinity correctly.
But, (0.0)==(-0.0) gives True!
Thus we need not write abs(x)==0.0 to test if x is zero (positive zero or negative zero)
but write just x==0.0
That's actually what the Fortran standard requires.
4.4.2.3 Real type
[...]
The real type includes a zero value. Processors that distinguish between positive and negative zeros shall treat
them as mathematically equivalent
• in all intrinsic relational operations,
See also Note 4.8 in that section of the standard.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
hiroshi-murakami wrote:
read(*,*)x ! this is very standard.
write(*,*)x ! this is very standard.
read(*,*),x ! ifort accepts this.
write(*,*),x ! ifort accepts this.
read(*,*), ! ifort accepts this also.
write(*,*), ! ifort accepts this also.
read*,,x ! ifort does not accept this.
print*,,x ! ifort does not accept this.
If you compile your program with standards checking enabled, you will get a message that your program is not standards-conforming.
Yes, Intel Fortran accepts the comma between the I/O specification and the I/O list as an extension.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Consecutive operators, such as ++ or -- are explicitly disallowed in the standard, though it can be exasperating trying to figure that out from the syntax rules. As said., we allow them as extensions. In fact, Intel Fortran, with its roots back to the 1970s DEC FORTRAN-IV-PLUS, allows a LOT of non-standard syntax by default. As required by the standard, we provide a "means of detection" of such non-standard syntax, but you have to ask for it.
One aspect of this that confuses many is that an entity such as -3 is actually two syntax tokens - the minus unary operator applied to the integer literal 3.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It would be preferable that the compiler detects every non-standard feature
used in the source code by default to promote the standard or the provider
is trying to lock users and codes.
It would be better for the historical features or the experimental ones,
they are enabled only by setting the corresponding compiler options
somthing such as "--intel".
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Our experience has been that the majority of customers prefer the compiler to be more relaxed by default, and we get many complaints when we tighten error checking. You can always make -stand be the default by adding it to an ifort.cfg file. See the documentation for information on how to use configuration files.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The intel Fortran compiler supports IEEE's quadruple precision floating point numbers.
I would like to know if the rounding mode of the arithmetics for the quadruple precision numbers
can be controlled by the mode flag for FPU and SSE unit as the usual hardware implemented
single or double precision numbers.
Does the software implementation of quadruple precision arithmetics used by the intel compiler reflects
the rounding mode control flags (round-up, round-down, round-nearest, round-to-zero) as if the Q-precision
is implemented by the hardware instructions.
The mode flag can be changed by the user by calling C with assembler routines.
If the rounding mode can be used to controll the Q-precision or Q and other precision arithmetics,
we can elegantly write code that enable interval arithmetics in Q-precision.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
If IEEE_set_rounding_mode et al. aren't working for you, why don't you file a reproducer?
Yes, for compilers such as gfortran which don't support IEEE_arithmetic, several of these functions can be written to support native floating point by iso_c_binding calls to e.g.
int ieee_set_rounding_mode(unsigned int rounding_mode) {
#ifdef HAVE_FENV
fesetround(rounding_mode);
#else // xmmintrin
_MM_SET_ROUNDING_MODE (rounding_mode);
#endif
}
but why would you bypass documented features of ifort in favor of hypothetical undocumented ones?
Even for gfortran libquadmath you would probably want to study the docoumentation and source code before launching off in such diirections.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I'm not completely sure that the IEEE_ARITHMETIC routines affect quadruple precision - they may, but I have a vague memory that says they don't. If not, then they would use the default mode which is "Round to nearest".
![](/skins/images/45C6C2D737ED71F4C51F0145C8CB1E9C/responsive_peak/images/icon_anonymous_message.png)
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page