I'm not sure why this is an error
Author 
Message 
psalz.. #1 / 21

I'm not sure why this is an error
this compiled fine under pgf90, but not absoft f90. i'm not *desperate* to have this code portable, but if i can make it portable with minimal effort, that would be hunky dory. the error is: wrong data type for argument 2 of intrinsic cmplx complex (kind=dp) :: c1, c2, c3 c1 = CMPLX( (beta/pi)**(.75_dp), KIND=dp ) c2 = CMPLX( m**2.0_dp + (m*t*beta*hbar)**2.0_dp, KIND=dp ) c3 = CMPLX( m**2.0_dp/c2, m*t*beta*hbar/c2, KIND=dp ) where m, t, beta, hbar and pi are all real(kind=dp) and dp = selected_real_kind(15,307) the line that the compiler chokes on is the last one; the assignment for c3. i can't figure out what's wrong with it. can someone help me out? thanks! pete

Wed, 18 Jun 1902 08:00:00 GMT 


Dick Hendrickso #2 / 21

I'm not sure why this is an error
Quote:
> this compiled fine under pgf90, but not absoft f90. i'm not *desperate* > to have this code portable, but if i can make it portable with minimal > effort, that would be hunky dory. > the error is: wrong data type for argument 2 of intrinsic cmplx > complex (kind=dp) :: c1, c2, c3 > c1 = CMPLX( (beta/pi)**(.75_dp), KIND=dp ) > c2 = CMPLX( m**2.0_dp + (m*t*beta*hbar)**2.0_dp, KIND=dp ) > c3 = CMPLX( m**2.0_dp/c2, m*t*beta*hbar/c2, KIND=dp ) > where m, t, beta, hbar and pi are all real(kind=dp) and > dp = selected_real_kind(15,307) > the line that the compiler chokes on is the last one; the assignment for c3. > i can't figure out what's wrong with it. can someone help me out?
You are trying to convert two complex values into a complex value and that isn't defined. The cmplx function will convert 2 noncomplex numeric values into a complex one or convert the kind of a complex value. If there is only one value it assumes 0.0 for the imaginary part. Do you want the real part of the first and the imaginary of the second? Or did you mistype the comma? maybe Quote: > c3 = CMPLX( m**2.0_dp/c2 m*t*beta*hbar/c2, KIND=dp )
^ or Quote: > c3 = CMPLX(real( m**2.0_dp/c2), aimag(m*t*beta*hbar/c2), KIND=dp )
hope this helps dick hendrickson Quote: > thanks! > pete

Wed, 18 Jun 1902 08:00:00 GMT 


Steven G. Kar #3 / 21

I'm not sure why this is an error
Quote: > this compiled fine under pgf90, but not absoft f90. i'm not *desperate* > to have this code portable, but if i can make it portable with minimal > effort, that would be hunky dory. > the error is: wrong data type for argument 2 of intrinsic cmplx > complex (kind=dp) :: c1, c2, c3 > c1 = CMPLX( (beta/pi)**(.75_dp), KIND=dp ) > c2 = CMPLX( m**2.0_dp + (m*t*beta*hbar)**2.0_dp, KIND=dp ) > c3 = CMPLX( m**2.0_dp/c2, m*t*beta*hbar/c2, KIND=dp )
According to Metcalf and Reid on page 176 (section 8.3.1), if the Y argument in CMPLX(X,Y,KIND) is present, then X and Y must be of type INTEGER or REAL. c2 is of type complex, so it appears you've found a bug in pgf90.  Steve

Wed, 18 Jun 1902 08:00:00 GMT 


psalz.. #4 / 21

I'm not sure why this is an error
Quote: >> c2 = CMPLX( m**2.0_dp + (m*t*beta*hbar)**2.0_dp, KIND=dp )
i originally set up these equations a bit differently, where c2 was complex. when i changed the expression, i 'reused' the CMPLX. i didn't think it would hurt anything, but i guess it does. actually, my fortran program is giving astoundingly good results for the real part of the wavefunction, but the imaginary part is off by a small amount (only getting 2 or 3 digits of precision). maybe this is the cause? i'll notify the portland group. thanks for helping me! pete

Wed, 18 Jun 1902 08:00:00 GMT 


Erik Schnette #5 / 21

I'm not sure why this is an error
Quote:
> this compiled fine under pgf90, but not absoft f90. i'm not *desperate* > to have this code portable, but if i can make it portable with minimal > effort, that would be hunky dory. > the error is: wrong data type for argument 2 of intrinsic cmplx > complex (kind=dp) :: c1, c2, c3 > c1 = CMPLX( (beta/pi)**(.75_dp), KIND=dp ) > c2 = CMPLX( m**2.0_dp + (m*t*beta*hbar)**2.0_dp, KIND=dp ) > c3 = CMPLX( m**2.0_dp/c2, m*t*beta*hbar/c2, KIND=dp ) > where m, t, beta, hbar and pi are all real(kind=dp) and > dp = selected_real_kind(15,307)
Now that your problem has been solved... Do you know that the operation "m**2.0_dp" is maybe much slower than the equivalent "m**2"? Many compilers produce faster code for integer exponents, and it reduces the visual clutter, too. (Sorry, couldn't resist) erik 
[That which does not kill us has made its last mistake.]

Wed, 18 Jun 1902 08:00:00 GMT 


Elizabeth Passan #6 / 21

I'm not sure why this is an error
Quote:
> Now that your problem has been solved... Do you know that the > operation "m**2.0_dp" is maybe much slower than the equivalent "m**2"? > Many compilers produce faster code for integer exponents, and it > reduces the visual clutter, too.
Would m*m be even faster, or is this no longer the case? I always rewrite (...)**2 to (...)*(...), but it lessens legability. Elizabeth

Wed, 18 Jun 1902 08:00:00 GMT 


Kurt Kaellbl #7 / 21

I'm not sure why this is an error
Quote:
>> Now that your problem has been solved... Do you know that the >> operation "m**2.0_dp" is maybe much slower than the equivalent "m**2"? >> Many compilers produce faster code for integer exponents, and it >> reduces the visual clutter, too. >Would m*m be even faster, or is this no longer the case? >I always rewrite (...)**2 to (...)*(...), but it lessens legability. >Elizabeth
CVF6.1 produces exactly the same assembly code (a simple multiplication) for x*x, x**2, x**2.0 and x**2.0d0 and I guess many others do the same. Cheers, Kurt Kurt Kaellblad, Ph.D. Dept. of Building Science Lund University, Sweden

Wed, 18 Jun 1902 08:00:00 GMT 


Jan Vorbruegge #8 / 21

I'm not sure why this is an error
Quote:
> CVF6.1 produces exactly the same assembly code (a simple multiplication) for > x*x, x**2, x**2.0 and x**2.0d0 and I guess many others do the same.
A certain other f90 compiler had, in an update released some months ago, a correction for a problem described as follows: Bad performance because x**1 has been replaced by x*1, not by x Duh... Jan

Wed, 18 Jun 1902 08:00:00 GMT 


Richard Main #9 / 21

I'm not sure why this is an error
Quote:
> CVF6.1 produces exactly the same assembly code (a simple multiplication) for > x*x, x**2, x**2.0 and x**2.0d0 and I guess many others do the same.
Note that, although some compilers may allow it, the expressions x**2.0 and x**2.0d0 are not even legal if x is negative. Nor can I see that they improve legibility over x**2. I find x**2 more legible. I really can't think of any reason to write x**2.0 except for habit of avoiding mixedmode expressions. But this case is different in that reasing a real to an integer power is really quite different from raising a real to a real power. Some compilers might recognize the special case, but it is not guaranteed. I'd say to generally use x**2 instead of x*x. Doesn't conceptually matter. Let the compiler figure out which is faster. It has a fair chance of doing it better that you would (particularly if the "x" is actually an expression instead of a simple variable). And at least either result is correct (unless there are side effects of evaluating x multiple times, which you shouldn't be depending on anyway). If the speed difference matters so much that you don't want to trust the compiler to get the fastest method, then you need to be testing instead of assuming anyway. But don't use x**2.0. Its just wrong  certainly if x can be negative. The compiler might happen to fix it for you, but its better to write it correctly than to assume that.  Richard Maine

Wed, 18 Jun 1902 08:00:00 GMT 


Toon Moen #10 / 21

I'm not sure why this is an error
Quote:
> > CVF6.1 produces exactly the same assembly code (a simple multiplication) for > > x*x, x**2, x**2.0 and x**2.0d0 and I guess many others do the same. > Note that, although some compilers may allow it, the expressions > x**2.0 and x**2.0d0 are not even legal if x is negative.
Which means that the compiler *can't* replace x**2.0 by x**2 if it doesn't know x is nonnegative (sorry for the triple negative in this sentence. Or is evaluating x**2 with x<0 an acceptable way to treat nonconforming code (hmmm, it probably is  WW III is a possible, not necessary outcome of performing nonconforming code ...) Quote: > I'd say to generally use x**2 instead of x*x. Doesn't conceptually > matter.
Not if it is just x**2. It's another matter if it's (blahblahblah complicated multiline expression)**2. In that case the compiler might have a hard time proving that _two_ occurrences of blahblahbla complicatedmultilineexpression are exactly the same. 
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands Phone: +31 346 214290; Fax: +31 346 214286 GNU Fortran: http://gcc.gnu.org/onlinedocs/g77_news.html

Wed, 18 Jun 1902 08:00:00 GMT 


Robert Corbe #11 / 21

I'm not sure why this is an error
Quote:
>> CVF6.1 produces exactly the same assembly code (a simple multiplication) for >> x*x, x**2, x**2.0 and x**2.0d0 and I guess many others do the same. >Note that, although some compilers may allow it, the expressions >x**2.0 and x**2.0d0 are not even legal if x is negative. Nor can I >see that they improve legibility over x**2. I find x**2 more >legible. I really can't think of any reason to write x**2.0 except for >habit of avoiding mixedmode expressions. But this case is different >in that reasing a real to an integer power is really quite different >from raising a real to a real power. Some compilers might recognize the >special case, but it is not guaranteed. >I'd say to generally use x**2 instead of x*x. Doesn't conceptually >matter. Let the compiler figure out which is faster. It has a fair >chance of doing it better that you would (particularly if the "x" is >actually an expression instead of a simple variable). And at least >either result is correct (unless there are side effects of evaluating >x multiple times, which you shouldn't be depending on anyway). If >the speed difference matters so much that you don't want to trust >the compiler to get the fastest method, then you need to be testing >instead of assuming anyway. >But don't use x**2.0. Its just wrong  certainly if x can be >negative. The compiler might happen to fix it for you, but its >better to write it correctly than to assume that. > >Richard Maine
I think X*X is safer than X**2. The only thing special about a real raised to an integer power that I can find in the Fortran standard is the statement When a value of type real or complex is raised to an integer power, the integer operand need not be converted. in Section 7.1.2. I do not understand that statement to mean that X**2 cannot be evaluated as X**2.0. Then again, the mathematical equivalence rule allows X*X to be evaluated as X**2.0. Sincerely, Bob Corbett

Wed, 18 Jun 1902 08:00:00 GMT 


Richard Main #12 / 21

I'm not sure why this is an error
Quote:
> in Section 7.1.2. I do not understand that statement to mean that > X**2 cannot be evaluated as X**2.0. Then again, the mathematical > equivalence rule allows X*X to be evaluated as X**2.0.
Yes, x**2 is mathematically equivalent to x*x. But I would say that x**2.0 is mathematically different. It isn't even defined for negative x. Well, one could play games to define it, but then one is likely to come up with a result that is complex, which I wouldn't consider mathematically equivalent. Such word quibbling aside, if the compiler can get the (approximately) right answer, then its allowed to do so, even if it does exp(2.*log(x)) for positive x. But if the compiler uses a supposed mathematical equivalence to claim that (7.0)*(7.0) is invalid because it is equivalent to (7.0)**2.0, then I don't think any of the customers will be interested in debating whether the standard allows this, so it seems a little moot. In the other direction, the standard is quite explicit that x**y is illegal when y is real and x is negative. A compiler clearly *MAY* apply the "obvious" fix to user code that does this, but that doesn't seem like much reason for a user to do it.  Richard Maine

Wed, 18 Jun 1902 08:00:00 GMT 


Tony T. Warnoc #13 / 21

I'm not sure why this is an error
Quote:
> >> CVF6.1 produces exactly the same assembly code (a simple multiplication) for > >> x*x, x**2, x**2.0 and x**2.0d0 and I guess many others do the same. > >Note that, although some compilers may allow it, the expressions > >x**2.0 and x**2.0d0 are not even legal if x is negative. Nor can I > >see that they improve legibility over x**2. I find x**2 more > >legible. I really can't think of any reason to write x**2.0 except for > >habit of avoiding mixedmode expressions. But this case is different > >in that reasing a real to an integer power is really quite different > >from raising a real to a real power. Some compilers might recognize the > >special case, but it is not guaranteed. > >I'd say to generally use x**2 instead of x*x. Doesn't conceptually > >matter. Let the compiler figure out which is faster. It has a fair > >chance of doing it better that you would (particularly if the "x" is > >actually an expression instead of a simple variable). And at least > >either result is correct (unless there are side effects of evaluating > >x multiple times, which you shouldn't be depending on anyway). If > >the speed difference matters so much that you don't want to trust > >the compiler to get the fastest method, then you need to be testing > >instead of assuming anyway. > >But don't use x**2.0. Its just wrong  certainly if x can be > >negative. The compiler might happen to fix it for you, but its > >better to write it correctly than to assume that. > > > >Richard Maine
> I think X*X is safer than X**2. The only thing special about a real > raised to an integer power that I can find in the Fortran standard > is the statement > When a value of type real or complex is raised to an > integer power, the integer operand need not be converted. > in Section 7.1.2. I do not understand that statement to mean that > X**2 cannot be evaluated as X**2.0. Then again, the mathematical > equivalence rule allows X*X to be evaluated as X**2.0. > Sincerely, > Bob Corbett
Actually X*X is not mathematically equivalent to X**2.0. The first is a product of a real with itself. The second is a real to a real power. The difference occurs if one writes X**Y where Y per accidens has the value 2.0. Tony

Wed, 18 Jun 1902 08:00:00 GMT 


Robert Corbe #14 / 21

I'm not sure why this is an error
Quote: >> in Section 7.1.2. I do not understand that statement to mean that >> X**2 cannot be evaluated as X**2.0. Then again, the mathematical >> equivalence rule allows X*X to be evaluated as X**2.0. >Actually X*X is not mathematically equivalent to X**2.0. The first is a product of >a real with itself. The second is a real to a real power. The difference occurs if >one writes X**Y where Y per accidens has the value 2.0.
Hmmm. This must be that new math. When I was in school, raising a number to the second power was the same as multiplying it by itself. I don't think you want to go far down this path. If you are saying that the standard does not allow an implementation to consider X*X mathematically equivalent to X**2.0, you are not only saying that X*X cannot be replaced with X**2.0, you are also saying that X**2.0 cannot be replaced with X*X. The mathematical equivalence rule is what allows both cases. Sincerely, Bob Corbett

Wed, 18 Jun 1902 08:00:00 GMT 


Richard Main #15 / 21

I'm not sure why this is an error
Quote:
> >Actually X*X is not mathematically equivalent to X**2.0. > Hmmm. This must be that new math. When I was in school, raising a number > to the second power was the same as multiplying it by itself. > I don't think you want to go far down this path. If you are saying that > the standard does not allow an implementation to consider X*X > mathematically equivalent to X**2.0, you are not only saying that > X*X cannot be replaced with X**2.0, you are also saying that X**2.0 > cannot be replaced with X*X. The mathematical equivalence rule is what > allows both cases.
Methinks you miss the point (either that or I do). The distinction here is because the number is being raised to a *REAL* power. I agree that x*x is mathematically equivalent to "x**2". I do not agree that is is equivalent to "x**2.0". There is a mathematical distinction between reals and integers  rather a major one actually. If anything, I'd say that the mathematical distinction between integers and reals is stronger than Fortran's distinction; they barely even share the same mathematical language it seems. I don't know of any way to define, for example x**1.999 as anything like multiplying x by itself 1.999 times. I do know how to define it as exp(log(x)*1.999) for positive x. Actually, that definition holds for negative x also, but then you have to be talking in the complex domain.  Richard Maine

Wed, 18 Jun 1902 08:00:00 GMT 


Page 1 of 2

[ 21 post ] 

Go to page:
[1]
[2] 
