I'm not sure why this is an error 
Author Message
 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  
 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 non-complex
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

- Show quoted text -

Quote:
> thanks!
> pete



Wed, 18 Jun 1902 08:00:00 GMT  
 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  
 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  
 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  
 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 re-write (...)**2 to (...)*(...), but it lessens legability.

Elizabeth



Wed, 18 Jun 1902 08:00:00 GMT  
 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 re-write (...)**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  
 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  
 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 mixed-mode 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  
 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 non-negative (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 non-conforming 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-
complicated-multiline-expression 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  
 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 mixed-mode 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  
 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  
 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 mixed-mode 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  
 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  
 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  
 
 [ 21 post ]  Go to page: [1] [2]

 Relevant Pages 

1. I should be sure but I am not

2. I'm not sure if this was posted before

3. $_GET variable variables, dynamic parsing (I'm not sure how to summarize this question)

4. Compile Question? (I'm not sure)

5. Why I am not enthusiatic about OO COBOL

6. Why I am not reaching callbacks ?

7. Why am I getting bind errors?

8. ERROR 48 - Why am I getting it?

9. why am i getting processor stack fault error?

10. Super URGENT Request - Easy answer I am sure

11. Why is interpreter not 'registered'?

12. I am not deaf, but am I mute?

 

 
Powered by phpBB® Forum Software