Home > Archive > Fortran > November 2007 > eqv vs ==
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
|
| Is it correct that I cannot use:
if (a == b) write(*,*) 'can do'
if a and b are both of the logical type (in case of fortran 95)?
Should i use instead:
if (a.eqv.b) write(*,*) 'can do'
Arno
| |
|
| == for logical variables is a compiler extension
..eqv. is the standard way to compare logical variables
Les
"Arno" <arnoinperu@hotmail.com> wrote in message
news:74c36721-30ac-4bf9-a30c-a1db8b2b9755@a28g2000hsc.googlegroups.com...
> Is it correct that I cannot use:
>
> if (a == b) write(*,*) 'can do'
>
> if a and b are both of the logical type (in case of fortran 95)?
> Should i use instead:
>
> if (a.eqv.b) write(*,*) 'can do'
>
> Arno
| |
| Tim Prince 2007-11-21, 7:11 pm |
| Arno wrote:
> Is it correct that I cannot use:
>
> if (a == b) write(*,*) 'can do'
>
> if a and b are both of the logical type (in case of fortran 95)?
> Should i use instead:
>
> if (a.eqv.b) write(*,*) 'can do'
If a compiler did implement the == operator as an extension for
logicals, you would have no guarantee whether it meant bit-wise
identity, or a synonym for .eqv. .eqv. is the standard operator, since
30 years ago, to inquire whether both operands are .false. or both
..true. Before f77, you would have had to write out
if(a .and. b .or. .not. a .and. .not. b)...
maybe with parens to make precedence explicit.
A more common situation was the writing of
if(x * y .ge. 0)..
in place of
if(x >= 0 .eqv. y >= 0)...
Extensions which allow non-standard operations on logicals without
warning have been a fruitful source of bugs. Besides not diagnosing
errors, they depend on implementation details such as whether .true. can
be depended on to be all bits on, or just certain bits.
| |
| Steve Lionel 2007-11-21, 7:11 pm |
| On Nov 21, 4:31 am, Arno <arnoinp...@hotmail.com> wrote:
> Is it correct that I cannot use:
>
> if (a == b) write(*,*) 'can do'
>
> if a and b are both of the logical type (in case of fortran 95)?
> Should i use instead:
>
> if (a.eqv.b) write(*,*) 'can do'
As others have said, == is not standard for logicals and can give you
unexpected results. I wrote an article on this topic some years ago -
you can find it at
http://softwarecommunity.intel.com/...ead.aspx#116164
Steve
| |
| Jugoslav Dujic 2007-11-22, 7:10 pm |
| Steve Lionel wrote:
| On Nov 21, 4:31 am, Arno <arnoinp...@hotmail.com> wrote:
|| Is it correct that I cannot use:
||
|| if (a == b) write(*,*) 'can do'
||
|| if a and b are both of the logical type (in case of fortran 95)?
|| Should i use instead:
||
|| if (a.eqv.b) write(*,*) 'can do'
|
| As others have said, == is not standard for logicals and can give you
| unexpected results. I wrote an article on this topic some years ago -
| you can find it at
|
http://softwarecommunity.intel.com/...ead.aspx#116164
<flame>
I was about to XXXXX on the feature this morning, but refrained, not wishing to
troll the group... By coincidence, I've just been bitten, wasting an hour
of my time, so I'll XXXXX after all:
A piece of code which, among other things, contained:
if (abs(rt(j,j1).gt.0)) then
produced unexpected results over and over again. Being tired, I was trying to
find the cause elsewhere, until finally I managed to conclude that I meant:
if (abs(rt(j,j1)).gt.0) then
The previous code contained an implicit conversion of logical to whatever, then
an implicit conversion of a whatever to a logical, yielding incorrect semantics,
and all without a hint or warning by the compiler (still CVF, I'm lazy to check
IVF10.1). All because someone in the past thought it was a  idea and all the
successor compilers being too backward-capability paranoid to ban the practice,
at least by the default set of options.
</flame>
--
Jugoslav
___________
www.xeffort.com
Please reply to the newsgroup.
You can find my real e-mail on my home page above.
| |
| Arjen Markus 2007-11-22, 7:10 pm |
| On 22 nov, 15:28, "Jugoslav Dujic" <jdu...@yahoo.com> wrote:
> Steve Lionel wrote:
>
> | On Nov 21, 4:31 am, Arno <arnoinp...@hotmail.com> wrote:
> || Is it correct that I cannot use:
> ||
> || if (a == b) write(*,*) 'can do'
> ||
> || if a and b are both of the logical type (in case of fortran 95)?
> || Should i use instead:
> ||
> || if (a.eqv.b) write(*,*) 'can do'
> |
> | As others have said, == is not standard for logicals and can give you
> | unexpected results. I wrote an article on this topic some years ago -
> | you can find it at
> |http://softwarecommunity.intel.com/...rums/permali...
>
> <flame>
> I was about to XXXXX on the feature this morning, but refrained, not wishing to
> troll the group... By coincidence, I've just been bitten, wasting an hour
> of my time, so I'll XXXXX after all:
>
> A piece of code which, among other things, contained:
>
> if (abs(rt(j,j1).gt.0)) then
>
> produced unexpected results over and over again. Being tired, I was trying to
> find the cause elsewhere, until finally I managed to conclude that I meant:
>
> if (abs(rt(j,j1)).gt.0) then
>
> The previous code contained an implicit conversion of logical to whatever, then
> an implicit conversion of a whatever to a logical, yielding incorrect semantics,
> and all without a hint or warning by the compiler (still CVF, I'm lazy to check
> IVF10.1). All because someone in the past thought it was a idea and all the
> successor compilers being too backward-capability paranoid to ban the practice,
> at least by the default set of options.
>
> </flame>
>
Over lunch, a colleague told me he had spent at least
an hour discovering a bug that seems fairly similar:
integer, dimension(10) :: intvalue
if ( intvalue(1) ) then
...
endif
It was accepted by CVF without protest but caused
strange effects when running the program. (Of course
it surfaced when he changed his input and parts of
the program).
Regards,
Arjen
| |
| Arjen Markus 2007-11-22, 7:10 pm |
| On 22 nov, 15:48, Arjen Markus <arjen.mar...@wldelft.nl> wrote:
> On 22 nov, 15:28, "Jugoslav Dujic" <jdu...@yahoo.com> wrote:
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Over lunch, a colleague told me he had spent at least
> an hour discovering a bug that seems fairly similar:
>
> integer, dimension(10) :: intvalue
>
> if ( intvalue(1) ) then
> ...
> endif
>
> It was accepted by CVF without protest but caused
> strange effects when running the program. (Of course
> it surfaced when he changed his input and parts of
> the program).
>
> Regards,
>
> Arjen- Tekst uit oorspronkelijk bericht niet weergeven -
>
> - Tekst uit oorspronkelijk bericht weergeven -
I checked Intel Fortran version 9.0 under Linux with this
program:
program test_ifs
integer, dimension(10) :: int_array
int_array = 1
if ( abs(int_array(1).gt.0) ) then
write(*,*) 'abs - true!'
endif
if ( int_array(2) ) then
write(*,*) 'int - true!'
endif
end program
Intel Fortran happily compiles it and the result is:
abs - true!
int - true!
g95 refuses to compile it, as does gfortran.
With the option -warn stderrors ifort also complains.
Which shows that it pays to have more than one compiler
at your disposal and that one needs to turn on as many
warnings as possible. Mind you: I do like the Intel
Fortran compiler, it produces fast programs.
Regards,
Arjen
| |
|
| Arjen Markus wrote:
> On 22 nov, 15:48, Arjen Markus <arjen.mar...@wldelft.nl> wrote:
>
> I checked Intel Fortran version 9.0 under Linux with this
> program:
>
> program test_ifs
>
> integer, dimension(10) :: int_array
>
> int_array = 1
>
> if ( abs(int_array(1).gt.0) ) then
> write(*,*) 'abs - true!'
> endif
>
> if ( int_array(2) ) then
> write(*,*) 'int - true!'
> endif
>
> end program
>
> Intel Fortran happily compiles it and the result is:
>
> abs - true!
> int - true!
>
> g95 refuses to compile it, as does gfortran.
>
> With the option -warn stderrors ifort also complains.
W/ the option /warn:[f95|f90] so does CVF...
--
| |
| Arjen Markus 2007-11-22, 7:10 pm |
| On 22 nov, 16:25, dpb <n...@non.net> wrote:
> Arjen Markus wrote:
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> W/ the option /warn:[f95|f90] so does CVF...
>
> --- Tekst uit oorspronkelijk bericht niet weergeven -
>
> - Tekst uit oorspronkelijk bericht weergeven -
That is good to know!
Regards,
Arjen
| |
| Jugoslav Dujic 2007-11-22, 7:10 pm |
| dpb wrote:
| Arjen Markus wrote:
|| On 22 nov, 15:48, Arjen Markus <arjen.mar...@wldelft.nl> wrote:
||| On 22 nov, 15:28, "Jugoslav Dujic" <jdu...@yahoo.com> wrote:
|| I checked Intel Fortran version 9.0 under Linux with this
|| program:
||
|| program test_ifs
||
|| integer, dimension(10) :: int_array
||
|| int_array = 1
||
|| if ( abs(int_array(1).gt.0) ) then
|| write(*,*) 'abs - true!'
|| endif
||
|| if ( int_array(2) ) then
|| write(*,*) 'int - true!'
|| endif
||
|| end program
||
|| Intel Fortran happily compiles it and the result is:
||
|| abs - true!
|| int - true!
||
|| g95 refuses to compile it, as does gfortran.
||
|| With the option -warn stderrors ifort also complains.
|
|
| W/ the option /warn:[f95|f90] so does CVF...
Yes, but VF has also been bitched at concerning the granularity of their
warning messages: you can get either none or all, and there's no extension
akin to #pragma warning(disable:).
In my case, the code heavily interfaces with C, and is loaded with conditional
compilation directives, cray pointers, and various !DEC$ATTRIBUTES. If I switch
/warn:f95 on, I'd get a ~1000 warnings about those (thanks, I know), likely
hiding the ones I *do* care about.
--
Jugoslav
___________
www.xeffort.com
Please reply to the newsgroup.
You can find my real e-mail on my home page above.
| |
|
| Jugoslav Dujic wrote:
> dpb wrote:
> | Arjen Markus wrote:
> || On 22 nov, 15:48, Arjen Markus <arjen.mar...@wldelft.nl> wrote:
> ||| On 22 nov, 15:28, "Jugoslav Dujic" <jdu...@yahoo.com> wrote:
> || I checked Intel Fortran version 9.0 under Linux with this
> || program:
> ||
> || program test_ifs
> ||
> || integer, dimension(10) :: int_array
> ||
> || int_array = 1
> ||
> || if ( abs(int_array(1).gt.0) ) then
> || write(*,*) 'abs - true!'
> || endif
> ||
> || if ( int_array(2) ) then
> || write(*,*) 'int - true!'
> || endif
> ||
> || end program
> ||
> || Intel Fortran happily compiles it and the result is:
> ||
> || abs - true!
> || int - true!
> ||
> || g95 refuses to compile it, as does gfortran.
> ||
> || With the option -warn stderrors ifort also complains.
> |
> |
> | W/ the option /warn:[f95|f90] so does CVF...
>
> Yes, but VF has also been bitched at concerning the granularity of their
> warning messages: you can get either none or all, and there's no extension
> akin to #pragma warning(disable:).
>
> In my case, the code heavily interfaces with C, and is loaded with conditional
> compilation directives, cray pointers, and various !DEC$ATTRIBUTES. If I switch
> /warn:f95 on, I'd get a ~1000 warnings about those (thanks, I know), likely
> hiding the ones I *do* care about.
I didn't say it was perfect... :)
I've lost it when the old Brief editor would no longer run under XP but
I had a macro that parsed the error file and was able to screen out at
least some of the more notable culprits like !DEC$, etc. I've been
writing so little real code since I essentially retired I haven't tried
to incorporate it into anything else so far. That kind of alternative
would be the best I could suggest for CVF, though. :(
--
--
| |
| Dan Nagle 2007-11-22, 7:10 pm |
| Hello,
Richard Maine wrote:
> Besides which, the default does really matter. When you have helpful
> diagnostic messages that are not enabled by default, all too often this
> ends up meaning that *AFTER* the programmer finds the bug by other
> means, he can then demonstrate how he could have gotten the compiler to
> help him. I've seen it many, many times. Yes, the programmer should have
> thought of using those options earlier, but all too often in practice it
> just doesn't happen that way.
>
> In my opinion, the default compiler settings ought to be ones that
> facilitate debugging.
>
> But it is clear to me that several vendors (not just DEC/Compaq/Intel)
> have different priorities. I am sure that those priorities are driven by
> customer input. No doubt many customers complain about all the warnings
> and would prefer the self-delusional comfort of seeing no warning
> messages by default. I think it unfortunate.
I couldn't agree more with Richard's above comments
if he were paying me megabucks per word to do so.
At least, turn on the whine-about-non-standard switch!
If needed, put as many extensions as you can in as few files
as you can and compile them separately. You can verify
that the set of warnings doesn't change unexpectedly
with an automated script.
--
Dan Nagle
Purple Sage Computing Solutions, Inc.
| |
| Richard Maine 2007-11-22, 7:10 pm |
| Dan Nagle <dannagle@verizon.net> wrote:
> I couldn't agree more with Richard's above comments
> if he were paying me megabucks per word to do so.
Angling for a raise, huh? :-)
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
| |
| Dan Nagle 2007-11-22, 7:10 pm |
| Hi,
Richard Maine wrote:
> Dan Nagle <dannagle@verizon.net> wrote:
>
>
> Angling for a raise, huh? :-)
Yea, $100 bucks a word just won't do.
Standing up for the rights of da woikin people.
--
Dan Nagle
Purple Sage Computing Solutions, Inc.
| |
| James Van Buskirk 2007-11-22, 7:10 pm |
| "Jugoslav Dujic" <jdujic@yahoo.com> wrote in message
news:5qlhugF107mi0U1@mid.individual.net...
> if (abs(rt(j,j1).gt.0)) then
Yes, that one has cost me time, too. Disabling a**-b*c and reading
anything starting with TtFf on list-directed input would also be nice.
--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end
| |
| Steve Lionel 2007-11-22, 7:10 pm |
| On Nov 22, 2:04 pm, "James Van Buskirk" <not_va...@comcast.net> wrote:
....
>
>
> Yes, that one has cost me time, too. Disabling a**-b*c and reading
> anything starting with TtFf on list-directed input would also be nice.
I would encourage you to submit a feature request to Intel Premier
Support requesting finer-grained control of diagnostics and
extensions. The diagnostics is something we are working on, but not
the extensions. If there are particular extensions you wish to
disable, please list them. Requests from actual customers carry more
weight in the product planning process.
Steve
| |
| John Harper 2007-11-22, 7:10 pm |
| In article <PUi1j.25959$9h.20847@trnddc07>,
Dan Nagle <dannagle@verizon.net> wrote:
>Hello,
>
>Richard Maine wrote:
>
....
....[color=darkred]
>I couldn't agree more with Richard's above comments
>if he were paying me megabucks per word to do so.
>
>At least, turn on the whine-about-non-standard switch!
I agree, but those switches are not infallible.
I have in the past posted a program here in which three compilers
failed to notice that a constraint was violated. And of course no
compiler can be expected to complain about a non-standard program
that violates neither a syntax rule nor a constraint.
-- John Harper, School of Mathematics, Statistics and Computer Science,
Victoria University, PO Box 600, Wellington 6140, New Zealand
e-mail john.harper@vuw.ac.nz phone (+64)(4)463 5341 fax (+64)(4)463 5045
| |
| Gary Scott 2007-11-23, 4:27 am |
| Dan Nagle wrote:
> Hi,
>
> Richard Maine wrote:
>
>
>
> Yea, $100 bucks a word just won't do.
>
> Standing up for the rights of da woikin people.
>
Gee, I only get like $3.20 per word. I'm in the wrong business.
--
Gary Scott
mailto:garylscott@sbcglobal dot net
Fortran Library: http://www.fortranlib.com
Support the Original G95 Project: http://www.g95.org
-OR-
Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html
If you want to do the impossible, don't hire an expert because he knows
it can't be done.
-- Henry Ford
| |
|
|
| glen herrmannsfeldt 2007-11-23, 8:08 am |
| Richard Maine wrote:
(snip)
> Besides which, the default does really matter. When you have helpful
> diagnostic messages that are not enabled by default, all too often this
> ends up meaning that *AFTER* the programmer finds the bug by other
> means, he can then demonstrate how he could have gotten the compiler to
> help him. I've seen it many, many times. Yes, the programmer should have
> thought of using those options earlier, but all too often in practice it
> just doesn't happen that way.
I 100% agree for warnings that the compiler can do accurately.
I am a little less sure for ones that aren't so accurate.
Some compilers try a little too hard to detect undefined variables,
for example, and detect ones that really are defined. For ones the
compiler can't reliably detect, I may not want the default turned on.
For ones that can be unambiguously detected, on sounds good to me.
> In my opinion, the default compiler settings ought to be ones that
> facilitate debugging.
> But it is clear to me that several vendors (not just DEC/Compaq/Intel)
> have different priorities. I am sure that those priorities are driven by
> customer input. No doubt many customers complain about all the warnings
> and would prefer the self-delusional comfort of seeing no warning
> messages by default. I think it unfortunate.
I agree.
-- glen
|
|
|
|
|