<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
	<channel>
		<title><![CDATA[Approximatrix Forums — Operands of comparison operator...]]></title>
		<link>https://forums.approximatrix.com/viewtopic.php?id=904</link>
		<atom:link href="https://forums.approximatrix.com/extern.php?action=feed&amp;tid=904&amp;type=rss" rel="self" type="application/rss+xml" />
		<description><![CDATA[The most recent posts in Operands of comparison operator....]]></description>
		<lastBuildDate>Wed, 12 Jul 2023 13:07:44 +0000</lastBuildDate>
		<generator>PunBB</generator>
		<item>
			<title><![CDATA[Re: Operands of comparison operator...]]></title>
			<link>https://forums.approximatrix.com/viewtopic.php?pid=4151#p4151</link>
			<description><![CDATA[<div class="quotebox"><cite>Norseman wrote:</cite><blockquote><p>From the snippet it seems the comparison would never work, anyway. Note that the arguments A and B on input are 4 characters with a trailing blank, while the comparison is against 3 characters. In theory it might work with IF (A(1:3) .EQ. &#039;XDO&#039;..etc..&nbsp; Reminds me of packing 4-byte HOLLERITH into INTEGER*4 (or even REAL*4) in FORTRAN IV. (*Shudders*)</p><p>I suggest to handle character strings as characters:-)</p></blockquote></div><p>It might be better in this case to use:</p><div class="codebox"><pre><code>IF (TRIM(A) .EQ. &#039;XDO&#039;) THEN</code></pre></div><p>so we&#039;re not getting everything messy with string indices.</p>]]></description>
			<author><![CDATA[null@example.com (jeff)]]></author>
			<pubDate>Wed, 12 Jul 2023 13:07:44 +0000</pubDate>
			<guid>https://forums.approximatrix.com/viewtopic.php?pid=4151#p4151</guid>
		</item>
		<item>
			<title><![CDATA[Re: Operands of comparison operator...]]></title>
			<link>https://forums.approximatrix.com/viewtopic.php?pid=4149#p4149</link>
			<description><![CDATA[<p>From the snippet it seems the comparison would never work, anyway. Note that the arguments A and B on input are 4 characters with a trailing blank, while the comparison is against 3 characters. In theory it might work with IF (A(1:3) .EQ. &#039;XDO&#039;..etc..&nbsp; Reminds me of packing 4-byte HOLLERITH into INTEGER*4 (or even REAL*4) in FORTRAN IV. (*Shudders*)</p><p>I suggest to handle character strings as characters:-)</p>]]></description>
			<author><![CDATA[null@example.com (Norseman)]]></author>
			<pubDate>Wed, 12 Jul 2023 12:22:09 +0000</pubDate>
			<guid>https://forums.approximatrix.com/viewtopic.php?pid=4149#p4149</guid>
		</item>
		<item>
			<title><![CDATA[Re: Operands of comparison operator...]]></title>
			<link>https://forums.approximatrix.com/viewtopic.php?pid=4141#p4141</link>
			<description><![CDATA[<p>Some Fortran dialects did used to be pretty flexible in regards to INTEGER/CHARACTER conversion, but our compiler will complain.&nbsp; I&#039;m not even sure it would be allowed by switching to &quot;legacy&quot; standard (in Project Options under &quot;Fortran,&quot; check &quot;Enforce Standard&quot;).</p><p>I think changing the declaration line to:</p><div class="codebox"><pre><code>      CHARACTER * 4 A,B</code></pre></div><p>should be sufficient.</p><p>Just to clarify, the <em>.EQ.</em> operator and its other dot-friends are still valid Fortran under the up-to-date standards.&nbsp; I often see brand new Fortran written using them because, in a way, <em>.EQ.</em> is more obvious than the == alternative.&nbsp; Additionally, developers still need to use <em>.AND.</em> and <em>.OR.</em>, for example, so it could be seen as being consistent.</p>]]></description>
			<author><![CDATA[null@example.com (jeff)]]></author>
			<pubDate>Mon, 03 Jul 2023 17:51:33 +0000</pubDate>
			<guid>https://forums.approximatrix.com/viewtopic.php?pid=4141#p4141</guid>
		</item>
		<item>
			<title><![CDATA[Re: Operands of comparison operator...]]></title>
			<link>https://forums.approximatrix.com/viewtopic.php?pid=4140#p4140</link>
			<description><![CDATA[<p>It might help if you mentioned which FORTRAN version you are compiling to. For example, is the FORTRAN 77 code being compiled as .f95?</p><p>I often struggle with the IF construction (it used to be so simple). One thing I&#039;ve done is replace all the .EQ. with ==</p><p>Because you are also using that period for &quot;.AND.&quot; and &quot;.OR.&quot;, it is so easy to get lost in the syntax (if .EQ. is even valid in your compiled version).</p><p>Most of my time isn&#039;t spent on &quot;how to do it&quot; algorithmically, it&#039;s how to do it in the current syntax.</p>]]></description>
			<author><![CDATA[null@example.com (designer)]]></author>
			<pubDate>Mon, 03 Jul 2023 16:38:59 +0000</pubDate>
			<guid>https://forums.approximatrix.com/viewtopic.php?pid=4140#p4140</guid>
		</item>
		<item>
			<title><![CDATA[Operands of comparison operator...]]></title>
			<link>https://forums.approximatrix.com/viewtopic.php?pid=4139#p4139</link>
			<description><![CDATA[<p>Hello all. </p><p>Is there a way to have the compiler allow this comparison? See below.</p><p>Error: Operands of comparison operator &#039;.eq.&#039; at (1) are INTEGER(4)/CHARACTER(3)</p><br /><p>Below are some code snippets from the original FORTRAN 77 code.</p><p>CALL INPUT( 1,&#039;XDO &#039;,&#039;XDI &#039;,XDO,XDI) </p><p>SUBROUTINE INPUT(K,A,B,C,D)<br />&nbsp; &nbsp; &nbsp; INTEGER * 4 A,B<br />51&nbsp; &nbsp; IF(A.EQ.&#039;XDO&#039;.AND.B.EQ.&#039;XDI&#039;)I=1</p><p>This results in: Error: Operands of comparison operator &#039;.eq.&#039; at (1) are INTEGER(4)/CHARACTER(3)</p><p>I am trying to preserve the original code in its entirety. If changes need to made to allow for the proper comparison, what would the change be?</p><p>Any help would be greatly appreciated. Thanks.</p>]]></description>
			<author><![CDATA[null@example.com (mdmfea)]]></author>
			<pubDate>Mon, 03 Jul 2023 12:38:37 +0000</pubDate>
			<guid>https://forums.approximatrix.com/viewtopic.php?pid=4139#p4139</guid>
		</item>
	</channel>
</rss>
